Lean Software Engineering

A perennial question in software development is whether or not software development can ever be considered engineering. The argument against usually involves fields like civil engineering, where a deep and well-defined body of knowledge is applied to a constrained problem domain with very high expectations of reliability and accountability. I’d have to give them that one, building software is probably not much like designing or building freeway overpasses.

I know an electrical engineer who works for the power utility. That application of electrical engineering is very much of the civil engineering variety. Power utility customers are not looking for big bullet lists of features, and do not expect any kind of exponential growth in capability from one year to the next. They are not looking for big innovations in the nature of electric power. They want reliable power with reliable pricing. That’s what they will want next year, too.

But not all engineering is like that. Most of the electrical engineers that I know are involved in product development. What’s more, since I’m a systems software engineer, most of the software developers I’ve had the good fortune to work with are actually electrical engineers by education. I have also had the opportunity to work closely with mechanical engineers and industrial designers. What I can tell you about the way that all of these people work, and work together is: It’s all the same! They are all variations on a theme.

Another argument made against software engineering is that it lacks the analytical rigor that characterizes mechanical or electrical engineering. To which I say: horseshit! The mathematics of software analysis might be different from that of more physics-based fields, but it is certainly not less rigorous. What is lacking in the software field is a culture of rigor. A body of knowledge exists that is not widely taught or applied. The sorry state of practice in software development is more about history and economics than it is about science.

While it’s true that building software is not much like building bridges, software development is a lot like product development. In fact, it’s not even correct to speak of an analogy between software and product development. Software development is product development. And this shows us both some missed opportunities and promise for the future.

Software development is pretty hard. There’s a great deal of literature about how to do it effectively. Product development is also pretty hard, and there’s a good body of literature about how to do that effectively. What strikes me as odd is that there’s not much overlap between these two bodies of knowledge. Software development methodology is too focused on things that are specific to software. Product development methodology speaks to many things that are essential to software that have been under-represented in software development literature. Software methodology’s understanding of the meaning of quality, reliability, and customer utility is positively retarded in comparison to the understanding of the broader product development community. Software leadership needs to climb out of its little box and see itself in the larger context if it ever expects to be taken seriously by other engineering fields.

And what do you know? The people involved in the stories about product development include a lot of engineers! The stories these engineers tell, the problems they face with customers, with management, with teamwork, it’s all the same. The fact that it’s all the same would be interesting by itself, but what’s more interesting is that different disciplines or industries have come up with different solutions than anything that’s in play in today’s software conversation. And often, they have come up with better analysis and better solutions than what software methodologists have managed to describe.

There are generalized engineering methods that are not about any particular type of engineering: Quality Function Deployment, Taguchi Robust Design, Axiomatic Design, TRIZ, Design for Six Sigma. These things are not about mechanical engineering, or electrical engineering, or chemical engineering. They are about systems engineering, systems that often include software. What they have to say about the behavior of systems applies to software as much as it applies to any other specific discipline. And what QFD or Taguchi have to say about the nature of quality is miles beyond most thinking in the software development literature (Watts, I’m looking at you!).

If you really want to make some progress in your understanding of the process of software engineering, look outside to the broader literature. Some good examples might include:

• Managing the Design Factory, Donald Reinertsen
• Quality Function Deployment, Lou Cohen
• Product Development for the Lean Enterprise, Michael Kennedy

If you’re really feeling ambitious:

• Design for Six Sigma, Yang and El Haik

And finally, a book that also takes up the argument I made here:

• Design for Trustworthy Software, Jayaswal and Patton