Development vs. Manufacturing

A colleague pointed me to the this link which is lecture notes from an MIT class. It points out some common fallacies (derived from a study by Yuko Fujigaki) in running software development and cites the classic mistake as running software development as you would run manufacturing.

What is pointed out is that the time management techniques used in running manufacturing cannot be associated with software development without modifications. What are those techniques, then, and what modifications are required?

Taking from another article on a blog that I enjoy by Jeff Atwood, there are some parallels between software development and manufacturing, but they're often misapplied.

In manufacturing, you spend a whole bunch of time up-front doing design work and end up with a blueprint for what you want to build. You (loosely speaking) feed that blueprint into a bunch of machines who churn out your end product The traditional software-as-manufacturing metaphor maps "creating blueprints" to "writing a spec", "bunch of machines" to "developers", and "end product" to the code that those developers produce.

The revised metaphor instead maps "creating blueprints" to "writing code", "bunch of machines" to "compiler", and your end product is the binaries that you produce.

Using this metaphor better emphazises the challenges and efficiencies of software development as compared to manufacturing.

First, it casts the coding process as the creative design step that it is, rather than suggesting that developers are a bunch of automatons that take specs in at one end and churn out software at the other.

Second, it acknowledges the need for a detailed spec, but casts the code itself in that role. After all, what more detailed spec of how software works is there than the code itself? And unlike real manufacturing where screwing up the blueprints and starting to manufacture something incorrectly is extremely costly, actually "manufacturing" something from code is essentially free. Appreciating this frees you up to try different things with your blueprints to see which one produces the best end product.

So what does that mean? It simply means that the idea that the actual process of writing code is often misconstrued as being the easier part once specs are developed. The truth is, once a real spec (and what specs actually are is a topic in and of itself) is produced, the fun begins. With a spec in hand, a developer has a roadmap, but faces all of the challenges of working within the current codebase (or architecting if it's turnkey work), stumbling on functions that weren't written with scope and expansion in mind, data models, interface design, etc...

What this boils down to is the notion of time management in the software development process. The analogy I often use when discussing time management is asking a mechanic how long it will take to fix your car when the only description of the problem he/she has is "it's broken." You can narrow it down for them a bit with "it won't run" or even further with "it will start but won't move" but even with that detail you're not going to get a straight answer. It's not until the mechanic has had a chance to look at the vehicle that you're going to get anything resembling a time and cost to fix the problem.

For some reason, that's usually not acceptable in software development. Hard dates are demanded, and the developer has to live up to that date. And of course, when that date turns out to be short sighted, what happens is a stressed developer hacks in bad code at the last minute if they don't fight back on the deadline. That process leads to a common cycle in development where bad code is deployed, bugs are discovered, a client becomes unhappy or unhappier, more deadlines are set for the bug fixes, rinse/repeat.

What can be done to solve these problems? First, management of software development need to be aware that the development process is more art than science. There is no one way to solve any problem, and it's the thought process that gets to any of the solutions that takes the bulk of the time on the project. Without intimate knowledge of the codebase and the requirements, a hard date is impossible to define. It becomes less impossible when those two are known entities, but stumbling blocks, interruptions, scope creep, and any number of things can push that date out.