Craig Castelaz's Blog

Community Archives

The Catastrophe Cycle

Like Joshua Marinacci How do you develop?, a number of programmers, including myself, have adopted a fairly iterative development style. For the most part, this has been a conscious decision. However, there are times when this isn't always so. Occasionally, the style has more to do with the nature of the work than with the desires of the developer.

I was recently preparing for a short presentation when I came across a paper* with a couple of graphs that really caught my eye. The paper had to do with the requirements gathering process, and how it can be monitored and managed. Tthe first graph that caught my eye described a straight-forward linear relationship between the time spent gathering requirements and mastering the complexities of a system. In other words, the more time you spend gathering, the more you understand. This certainly seems intuitive, and it is how most of us model the process in our heads. Unfortunately, the model has little to do with reality. What the researchers actually found is reflected in the graph below.

Essentially, there are periodic breakdowns in the requirements gathering process. The researchers call these breakdowns, "catastrophe cycles", and largely attributed them to a form of information or complexity overload. That is, requirements engineers apparently gather until they go catatonic over the details. When they reach this point, they need to sit back and digest before they are ready for the next round. Slippage is inevitable, and there is a sense of three-steps-forward, one-step-back to it all. However, what I found paricularly interesting besides the discountinuities themselves was the researchers' belief that any requirements gathering process that doesn't experience these catastrophic breakdowns may actually be in trouble. There is a strong implication that it is impossible to have one without the other.

I don't believe it takes much imagination to apply a similar understanding to most phases of development. We've all experienced catastrophic breakdowns in our projects, and they haven't been limited to just the reguirements phase. Applying time to mastering complexity works. It just doesn't work as smoothly as we expect.

Perhaps, I should rephrase my earlier statement about adopting an iterative style as a conscious choice. Maybe it would be truer to say, at least in my case, that I've come to realize that development isn't a straight, upbroken line from start to finish, and that trying to make it so isn't worth the effort. Like Dr. Strangelove who came to love the bomb, I've come to love the catastrophe cycle. I've come to accept an iterative style not only as a personal choice, but also as a reflection of the nature of the development process itself.

Are Encapsulation, Polymorphism, and Inheritance peers?

I spend most of my time as a Java developer happily writing code without explicitly thinking about encapsulation, polymorphism, and inheritance as underlying principles. I mean those things are given. It would be like noticing wheels are round each time I get in my car. Just like I exploit the roundness of my tires as I tool down the street, I make use of the object-oriented features of Java without necessarily being consciously aware that is what I'm doing.

This isn't to say I drive with my head stored in the trunk, or that I have it shoved somewhere else when I code. Although my family and co-workers may have other opinions, I like to believe I'm concentrating on the things that matter most whether I'm driving or programming. In the case of programming this would include things like fulfilling the spec, designing a system that is maintainable, and writing code that is readable. I don't set out to create a program that exploits polymorphism. I create a program to solve a problem. Encapsulation, polymorphism, and inheritance are means towards that end. They are not the goals.

On the other hand, I'm not neutral in my use of these object-oriented features. When I reflect upon past work, I detect a strong pattern in my code. My greatest concern seems to be with encapsulation. I like to keep as much as I can private. I'm pretty stingy with the public keyword, and rarely, if ever, use protected. Polymorphism creeps silently into a number of my projects, but mostly as separate implementations of a common interface, rather than through extension of another class. In other words, my code tends to emphasis polymorphism over inheritance.

I suspect most of these inclinations date back to my years as a C programmer. I originally encountered the ideas behind The Big Three of OO while coding in that language. I was already doing both encapsulation and polymorphism through the use of module-level variables and function pointers, but without the cool names for the practice. When I migrated over to a true OO language, those two concepts traveled with me. Perhaps I've been damaged somewhere along the line, but I fear inheritance will always come up third in my personal OO lexicon.

Then again, isn't that the real beauty of a rich language like Java. While we can discuss and debate the relative merits of one approach over another, the language is open and flexible enough to allow different interpretations of what is important, and how it should be used.

Robogrammer 2303

Predictions do little for me. If they're in the near term, they're just stating the obvious, and if they're far into the future, they seem pointless. On the other hand, it is fun to speculate. In a recent blog, James Gosling mentioned he still dips into C on occassion. What this says about the language is interesting, but what it says about programming is even more so. C is 30 years old! What will coding be like in another 30? What languages will programmers use? Will there still be IDEs? What sort of platforms will they write against?

If we jump 300 years into the future, maybe only androids will code. As Chris Adamson mentioned in his blog, Widgets follow form follows function, Data's fingers fly across the control panel in STNG. (The mechanical speed of his typing is blinding, just think of his productivity if he used a USB!) While we can't assume the computer Data is controlling operates on a series of zeros and ones streaming through a set of processors, we should be able to assume that at the heart of it there is some form of source code which defined it's kernel. Where did it come from? Who created it? What does its syntax look like? Is it compiled, interpreted, or something entirely different?

Java is a fairly young language with hopefully a long life ahead of it. Perhaps it will outlive us all. Who knows, it could be the first language some real-life Data cuts his teeth on as a cub programmer.

Development Tug-o-War

Sun wants to dramatically increase the number of Java developers with Rave. They believe a significant portion of this increase will be accomplished by broadening the audience rather than converting existing developers. Many of these new faces will be end-users, or domain-experts. Rave promises to introduce a significant number of non-traditional programmers to the ranks of Java developers.

This isn't necessarily a bad thing. Amateur and professional developers tend to inhabit different areas of the programming spectrum. Each group experiences development from different perspectives and responsibilities. There is little overlap between them. Yet, there is tension between the groups. Wizard-enabled amateurs create applications quickly and easily, and wonder why the professionals are sooooo slooooow, and always act like they're overburdened. The professionals, on the other hand, roll their eyes and sigh as they attempt to scale a quick-and-dirty application, or pick up the pieces of a brittle one-off turned mission critical.

Rave will not be alone in helping to foster this tug-o-war, there are currently plenty of tools that allow the two groups to clash. Nor, is it like the tug-o-war is a recent phenomenon. The roots of the tension can be traced back to early spreadsheets like VisiCalc, and can be found in the old engineers vs. hobbyists debate surrounding Turbo Pascal.

There are interesting days ahead for Java, and it isn't just in terms of technology.

This work is licensed under a Creative Commons License.