More software projects have gone awry for lack of calendar time than for all other causes combined.
As a corollary to this, I’d say that lack of calendar time very often forces us to admit that our projects have gone awry.
Denial is a viable strategy when delivery dates are far in the future, but when the deadline is staring you right in the teeth, the time for sunny optimism is over and the time for the Day of Reckoning (DoR) meeting is at hand.
I attended one such DoR meeting yesterday afternoon . . .
This particular meeting broke down into a battle between the Designers and the Implementers. The Designers — who happen to be the more senior members of the team — felt that they had written the specs in such excruciating detail that the system should pretty much have coded itself from that point on, despite the relative inexperience of the Implementers.
The fact that this didn’t happen was frustrating to both factions. The Designers think the Implementers are incompetent; the Implementers think the Designers are arrogant.
Let me say here that if my life depended on delivering a project successfully, I would want to follow at least two simple rules, namely:
- Keep it simple.
- Deliver early and often.
At every DoR meeting I’ve ever been to — and I’ve been to quite a few over the years — one or both of these rules has been violated.
Yesterday was no exception.
Rule One violated
The company I’m working with is a believer in big upfront designs. On this project, the Designers were allowed to generate hundreds of pages of design docs, models, diagrams — then hand it off to the Implementers to implement.
The design is way beyond the ability of human beings to comprehend in its entirety. You’d have to be some kind of savant to keep that much information in your head and feel a sense of mastery of it. Software development is a technical process, but it’s also a people process, and you have to work within the limits of human comprehension.
Rule Two violated
You can’t really assess the efficacy of a design until you try to implement it — except to say that it’s almost certainly wrong in some respects — for the following reason:
If you were assigned to model an existing system of moderate complexity in perfect detail — well, I don’t know you, but I feel safe in saying that you probably couldn’t do it.
You’d get some things wrong, you’d leave some things out . . .
Now if you were assigned to model a system that hasn’t been built yet in perfect detail, just working from a set of requirements — well, that is an impossible task.
And even if you could do it, you’d find that in the course of building the system, forces beyond your control would inevitably lead to requirements changes, thus invalidating your model.
Bubbles and Lines
Bubbles and lines don’t crash.
Nothing ever breaks during the design process. Bubbles and lines don’t crash — code crashes!
So if you defer the writing of code until the big upfront design is done, you wind up learning things late that you would have been much better off learning early, when you still had time to do something about them.
Again, if my life depended on a successful project delivery, I’d start with early delivery of a working system that did almost nothing, but had the basic infrastructure in place — the essential hardware, software and network connections — then start adding to it, one piece at a time.
Summary
- Keep it simple.
- Deliver early and often.
Thus spoke The Programmer.