Some time back, I watched a video David Heinemeier Hansson give a talk on ActiveResource on RailsConf. The thing that struck me is how much Rails’ ideas are connected to those of Domain-Driven Design. Watching DHH is like seeing a version of Eric Evans on speed.
Based on the US Department of Defense standard DOD-STD-2167A, we have a well-defined process often referred to as Waterfall. If you are not familiar with the process, here is a short introduction.
A project in the waterfall process goes through four phases before the project is completed.
The first phase is the naïvite phase. This phase should always last 12, 18 or 24 months. 18 months is recommended. There is a detailed plan showing how, at the end of the phase, the system will be done.
After 18 months and 1 day, the project notices two things: 1) They’re not done, and 2) nobody had imagined this possibility.
This is the introduction to the second phase, which usually is the most frustrating of the project: The Panic phase. The Panic phase always lasts 2 or 6 months. 6 months is recommended. During the panic phase, a new plan is made, and everyone works overtime and weekends.
After 6 months and 1 day, the project notices two things: 1) They’re still not done, and 2) nobody cares anymore.
Thus begins the third phase of the waterfall project: The Sliding phase. At this point in time, nobody cares to update the plan and everyone continues to work, although at a more disillusioned pace. The sliding phase lasts for as long as it lasts, but seldom less than 6 months. Cases of up to 2 years have been documented.
The sliding phase ends when somebody finally puts the foot down, and the project enters the final phase of the waterfall cycle: The iterative phase. At this point in time, the project has usually produced quite a bit of software, but they have no idea of how to finalize it. The project comes up with a plan to deliver the project in increments of no more than 3-6 months, and manages to deliver the project within a year in several increments, thus completing yet another successful waterfall project.
In a recent thread on the Pragmatic Programmer mailing list, Dave Stagner said:
[….] I think most software hovers near the border between “barely works” and “almost works”.
Lately, I have had the rather dubious pleasure of reviewing some of our existing systems and find a plan for improving the maintainability of these systems. I have not done much work like this before, and I came in unprepared for the experience.
Most systems that have been maintained for a number of years have a maddening complexity, especially if they include a range of technological elements. Cramming the systems into my head completely enough to not make recommendations that are counter productive when they are faced with reality requires me to digest a lot of detailed information from many sources.
Updated (again) based on comments from helpful readers
Recently, I have discovered that managers who come into Java projects are totally unprepared for the reality that they face. Some programming environments have been basically stable for decades. COBOL has been stable from before most of us were born! But Java is different.
There are a few things you need to understand about Java. First of all, Java is not a programming language. It is what many call a technology ecosystem. It consists of the technical foundations in the Java language and virtual machine, but also of a growing set of library functionality in the Java platform itself, and made available through open-source projects. Last, and perhaps, most important, there are strong cultural movements within the Java space. Many developers, and especially brilliant developers, will be committed to one or more of these cultural movements. The cultural movements, like any cultural movements are not static.
How do you control an agile project? I have had many discussions with people lately about how to manage the budget and estimation of an agile project. The following post argues that a project with a business case of $20 million should deliver in steps of no more than $500,000. The argument is sadly only based on “common sense”, and not on actual project experience. (There are too few Agile managers in Oslo)
Subscribe (atom)