OK, So Maybe Software Development Isn’t Engineering After All

Developers can learn a thing or two from the lean and mean manufacturing and design methods.

• By Mike Gunderloy
• 10/12/2005

We all know the fable of the blind men and the elephant, how each of them was so sure that they knew what this fabulous beast was based on limited knowledge of a particular part that they practically came to blows when disputing their findings. I was reminded of this recently when reading Mary and Tom Poppendieck’s Lean Software Development (Addison-Wesley, 2003), which strongly suggests that our tunnel-vision about software development -- specifically, our dogged determination to view it as an engineering field -- has led us astray. The Poppendiecks bring to bear some of the lessons of lean product development from manufacturing companies in seeking to understand how software development can be made a more profitable endeavor. This slim, 200-page volume is the sort of thing you can give your manager when you’re looking for good arguments that an agile process is right for your shop. But is it the sort of book that you can actually learn anything from?

Change is Never Easy
A lot of us have been leaning on the side of the software elephant labeled “engineering” for so long that it’s tough for us to see the field any other way. Even those of us with degrees in more traditional engineering fields, who probably ought to know better, persist in calling ourselves “software engineers.” That’s despite the fact that building software bears very little resemblance to engineering when you stop to think of it, at least to the sort of engineering practices by, say, mechanical engineers or electrical engineers, who can apply a settled body of scientific and mathematical principles to their work. But take off your engineering blinders for a few hours and read this book, and you might come to appreciate that at least part of our elephant looks like manufacturing. Which is to say that we can learn about manufacturing software from the lessons of manufacturing cars, washing machines, and other real-world widgets.

Of course, manufacturing has undergone many changes over the years, from the flint-tool workshops of Olduvai Gorge to the latest automated robotic cells. The Poppendiecks focus their attention on one particular thread of modern thinking in manufacturing and product design: lean principles, which seek to eliminate waste in the manufacturing process. (Note the distinction between principles, which are universal, and practices, which apply principles in a particular environment). Lean principles resonate well with the current software interest in extreme programming (XP) practices, but a lean software development organization is not necessarily one that has embraced XP wholeheartedly. One nice thing about this book is that it argues consistently for evaluating what works in your own organization, rather than trying to follow cookbook recipes that may or may not apply.

Principles and Tools
Lean Software Development is organized around eleven chapters, each of which is devoted to one of the agile principles that the authors identify:

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole

Some of these skate pretty close to platitude territory; it’s difficult to imagine anyone who would disagree with empowering the team these days (or at least to imagine anyone who would be so foolish as to put such disagreement in writing). The value of the book goes well beyond this organization in two areas, though. First, the authors do an excellent job of teasing out how these principles, discovered in the course of building lean product development organizations, can be applied to software development. Second, they subdivide the chapters into sections dealing with 22 tools that help focus the principles further.

Don’t get fooled by the word “tools” into thinking of compilers and linkers. These are tools of a more philosophical or managerial sort. For example, one of the tools in the chapter on deciding as late as possible is “options thinking”: a discussion of keeping your options open so that you need not commit resources until they’re really required. As another example, you’ll find “Expertise” as one of the tools to use for empowering teams -- with an in-depth look at the benefits from working to actually develop the expertise that’s already lurking within your teams, instead of trying to impose top-down heavy methodologies on them.

One for the Managers
Ironically enough, one of the nicest things about this book from the working developer’s point of view is its utter lack of source code. It doesn’t even recommend particular software development tools, practices (beyond such bottom-line hygiene things as source code control), or programming techniques. This makes it eminently suitable for those folks up the management ladder who might not have a great grasp of precisely what the folks on the coding front lines are doing, but who still have the responsibility of maximizing productivity.

This book can be a great adjunct to a sales pitch that goes something like this: “Look, we’ve got a nearly impossible delivery schedule on the current project. If we’re buried in process and paperwork, we’ll never make it. But if you can cut through some of the red tape for us, and make it possible for us to actually do our jobs without waste, we’ll make it. Here are some ways we could revise the process to make it more efficient.” Maybe your manager won’t take the chance, in which case you’ll be no worse off than you are now. But if you’re lucky, this book can be a lever to help move things towards a more flexible world, in which the developers are more empowered and software actually gets developed in a way that makes sense.

But Remember: An Elephant is Not a Wall
The ideas in this book can be very seductive, especially to those who are tired of the waterfall methodology and the process involved in big up-front design. Even so, you need to exercise a bit of caution before plunging wholeheartedly into lean software development. The book is supported by plenty of evidence from manufacturing, notably stories about how Japanese automakers succeeded with lean techniques. But it’s a fallacy to argue that the success was directly dependent on the lean techniques; a few anecdotes do not prove any causal relationship. There are many differences between the average American software shop and a Japanese automaker, and more American software developers would probably not care to live in a Japanese society. It’s tempting, but not logical, to suppose that only the changes we’d like to see are the ones that will bring about success.

Finally, remember that even if building software isn’t engineering, it isn’t manufacturing cars either. We can draw lessons from both of those fields (as well as from construction, accounting, and even restaurant management), but ultimately we need to continue to experiment and develop our own repertoire of working practices. The Poppendiecks are very good about emphasizing the need to develop practices that work in your own organization. Just be sure that you don’t skip over that part of their very useful book in your search for new ideas.

Want to read more of Mike’s work? Visit his Larkware site for daily updates at http://www.larkware.com.