eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Like model years in Detroit, it seems as if the new year for book publishers starts in the fall. I just received a new book with a copyright date of 2007, “Implementing Lean Software Development: From Concept to Cash,” by Mary and Tom Poppendieck (Addison-Wesley Professional).
Wonderful, I thought. Ive only just finished teaching my editors that developers use “agile” (short for “agile methods”) as a noun. Ill bet that “lean” is next. Whether or not the term catches on, the book is usefully concise and densely packed with convincing stories about good practices that have transformed projects—often despite initial skepticism from developer teams.
About a quarter of the way into the book, I ran across something rare: a list of basic principles of productive software development I actually had never seen before. Even better, this looked like a list that might be effective in shaking up peoples ideas of (what may not be) necessary evils.
Guru Jakob Nielsen offers advice on designing applications for usability.
Click here
to watch the video.
Shigeo Shingos original list of “The Seven Wastes of Manufacturing” is well-known, the Poppendiecks say, among those who use “lean” (I told you it was the new noun) in manufacturing. Since its a widely held goal that software development should become more of a process of production and less of a guildsmans craft, its logical to seek to improve development using manufacturing disciplines—and theyve modified Shingos list to that end.
In manufacturing, weve heard for years that its vital to shrink in-process inventories from both ends—to deliver input just in time and to build to order rather than keeping finished goods expensively stored as their market value falls. The Poppendiecks redefine this for developers as the problem of “partially done work.” They apply that label to change requests that wait for years to get attention, to code thats done but has not been tested, and to code thats tested and ready to go but that sits undeployed.
Id therefore urge that users get prompt and honest feedback about when (if ever) their requests will be fulfilled; that code be tested as close as possible to the time and place of development; and that useful functionality should be delivered—for example, through a service interface—immediately upon completion of work.
Manufacturing gurus who espouse lean call overproduction the worst of the Seven Wastes. The analogous fault in software development, the Poppendiecks say, is the design and coding of features that no customer task actually requires. Ill add my own spin on “requires” in an economic sense—I dont mean a feature that no customer wants; I mean one that no customer would request if that customer knew upfront what it would cost in terms of delivery delay, performance handicap and reliability reduction of the code.
In a previous career, when I got the chance to ask a paying customer, “Would you want that feature if it took more than X seconds to work or if it required more than Y additional hardware?” I found that desire rarely turned into requirement.
Another of the Seven Wastes I had not considered before is the one the Poppendiecks label “handoffs,” which they compare to Shingos “waste” of transportation in manufacturing. “When work is handed off to colleagues,” the Poppendiecks observe, “a vast amount of tacit knowledge is left behind in the mind of the originator.”
If we fail to convey as much as half of our relevant knowledge when we hand off a task—a conservative estimate, the authors assert and I agree—then by the third such handoff, the person now stuck with some part of the original task is trying to do it with one-eighth the knowledge originally available for the job. Cross-functional design-and-build teams, improved communications (almost anything is better than written documents) and plenty of feedback loops to call prompt attention to misunderstandings are among the practices that “Implementing Lean Software Development” recommends.
Im implementing leanness myself by not going into all seven elements of the list. You dont need to be told again, for example, that defects are wasteful and worth killing upfront. The things Ive mentioned here are enough of an agenda to keep most teams busy for now.
Peter Coffee can be reached at [email protected].
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.