coneblog

Highly structured projects seem to work for other crafts, not so much for software. Why is that?

Projects with well-defined, sequential phases are often described as “waterfall model” in the software industry. Projects structured in this way are the standard in construction, for instance. In Construction, you absolutely have to erect the structural steel before you pour the floors. But in software, waterfall projects were found to suffer from several problems:

- It took too long to define every detail of the project in Requirements or Design form. Once you did, there was a whole maintenance cycle around the documentation.

- The design process was often carried out by technicians who didn’t understand the business objectives and organizational barriers, and key insights were missed – until the system went live, when the flaws were all too apparent – reference my eight guys in a room post.

- The process was not sufficiently flexible to handle the inevitable changes and miscalculations that occur during execution.

As a result, various agile methods and approaches have emerged in recent years, all attempting to introduce greater or lesser degrees of flexibility.

The above thinking raises an important question, which is this: “Why does the waterfall system work for complex construction projects, but not for complex software projects?” I have given considerable thought to this question, and here are some of my ponderings:

1) Mankind has been building buildings for six thousand years, but has only building software for a few decades. We said this back in the eighties, and maybe it held some water then, but now, 50 years after the birth of significant assembler and autocoder systems in the fifties, can we really say this? We as a profession have had plenty of tries to figure out how to build software. It is not for lack of experience, or trials.

2) Software is more complex than a construction project. Not true. All you have to do is watch Megaprojects on the Discovery channel to lose this conceit. There are some ways that a software project is more complex (more different types of users, functions and interfaces) but certainly not from a project complexity point of view

3) Software requirements are more plastic. In construction, they agree on the blueprint, and that’s what is built. This is true. In construction, the plan is detailed down to every nut and bolt, with just minor field modifications. When we try this in software, it takes too long, and isn’t flexible enough to capture the changing and emerging user requirements. I recall the old developers’ lament – “Why can’t Users just tell us what they need/want?”

4) The tools in Construction are more specialized and effective. I think this is somewhat true – every craft and function uses specialized tools and techniques to accomplish their job. Not so much true in Software – we all use the same basic set of UI builders, coding tools, and debuggers – mostly in the IDE. True, the testers and the Business Analysts have specialized toolsets, as do the DBAs. But crafts have more and varied tools in construction.

5) The crafts in construction are more specialized. This is certainly true. The Plumbers, carpenters, ironworkers, crane operators, etc. are all distinct crafts, with distinct roles, tools and phases of the project. This is emerging in recent decades in software, with distinct quality, coding, DBA, Architecture, and Business Analyst roles, but the tools, techniques, and handoffs are less well defined.

Where, then can we look for a construction model that might be useful in our thinking about software?

Next – the motion picture industry.