When consulting with organizations to establish a software process improvement program, one of my initial questions is, “Why do you want to do this?” The responses that I hear most often relate to the issue of software development productivity:
“We need to be more productive!”
“We need to be more responsive to our customers!”
“We need to do more with less!”
“We need to be ‘lean mean coding machines’!”
This is not a new concept. Since the dawn of the industrial age, captains of industry have focused on ways to improve the productivity of their workforce. One of the big lessons learned decades ago was that companies that only chased after productivity usually didn’t get the improvement that they wanted. And when they blindly focused on productivity, other things got worse. Sloppy work produced defective products. Customer and employee satisfaction deteriorated.
Something that the quality gurus of yore learned a long time ago was that focusing on quality actually improved productivity. What do we mean by quality in this context? Let’s call quality “Doing it right the first time.” Actually, that may be even too high of an ideal. Let’s adjust quality to be “Doing it as good as possible each time.” Rather than demanding perfection, focus on continuous improvement.
Historically, when companies began focusing on quality, the reduction in rework (from doing it better the first time) resulted in an indirect but tangible improvement in productivity. Rework in a manufacturing environment is something that you can see and touch. Defective products have to be set aside. They can’t be shipped. They need to be scrapped, repaired, or melted down and remanufactured. Unless, of course, the company doesn’t really care about quality, in which case anything can be shipped!
But in software, we have the “magic delete key.” We can delete characters, lines of code or text, paragraphs or programs, directories, or even entire disks! And the stuff is “deleted.” It goes away, nice and clean!
Years ago, an organization that I know performed an interesting experiment. They gathered their software developers together at the beginning of a project and announced, “We are doing this project in our typical way. But we would like to add something. So, whenever you have to change the code, either because you found a “bug”, or a requirement was misunderstood (or missing), or the design was wrong, or one of our tests or reviews finds a defect &endash; please change the code the way you normally would. But add one additional step: Before you modify or delete the code, send the lines of code to be modified/deleted to a special directory on a shared server.” They put someone in charge of organizing and keeping track of the deleted/modified lines of code. At the end of the experiment, the company discovered that for every line of code that they shipped after all of their testing was completed, they had actually written ten lines of code! This was a major revelation! They could double their productivity and still be only 20% efficient!
Rework in software is a tremendous problem that is largely ignored today. Every time you change a line of code or a line of text in a document (to correct a problem, not add a new feature), that’s rework. And, since software development is labor intensive and the labor is usually not cheap, it’s expensive rework. So when you hear a success story about how an organization became more productive through software process improvement or increased attention to planning, requirements, design, testing, or reviews &endash; it’s not because their programmers are somehow writing more lines of code per fortnight. It’s that they’re not rewriting as much code as they used to do!
So if quality means: “Doing as good as possible each time, ideally doing it right the first time,” how do you know what “doing it right” means? If you focus on what code or documentation needs to be rewritten and then why it needs to be rewritten, the “why” probably points to the aspect of your process that should be improved. For example, if code has to be rewritten because a requirement was misunderstood, what do you know now (that you’re rewriting) that you didn’t know then? And what could you have done differently back then to avoid the problem now?
Isn’t it strange how software rework continues to be largely ignored despite the popularity of the well-known adage: “There’s never enough time to do it right but there’s always enough time to do it over!”
© Mark Manduke, 2001