Accelerating Software Quality Using the 4-50 Rule
Blog

Accelerating Software Quality Using the 4-50 Rule

Leaders, managers and programmers sometimes get frustrated with software systems and try to rewrite them. This usually fails. It is possible to use Six Sigma and the 4-50 rule to find and fix the few code modules that have the most bugs and require the most enhancements. This delivers software quality without the high cost and risk. Here’s how:

“Hi, I’m Jay Arthur, author of “Lean Six Sigma Demystified” and the QI Macros [software].

“Today I want to talk to you about software. Now, some of you may work in software, some of you may use software… (If you have a phone, you’re using software) There’s lots of software around, and sometimes there’s bugs and stuff like that, and sometimes we’re enhancing things. (I don’t know about you, but I get an update from Apple, like every afternoon or something… What? You can’t be making it that much better that quickly; it’s just not possible.)

“I had this weird dream the other morning before I woke up: I was talking to my boss about software and how we don’t need to rewrite all this software. When I was in the phone company we had something called Customer Record Information System, or CRIS for short, and this thing embodied all of the ways that we billed customers. They kept trying to rewrite this thing and spent hundreds of millions of dollars trying to do it, but so much of the information was embedded in the knowledge of the system that you couldn’t write requirements and build the system again.

“One of the things I was trying to explain to him was, “Look, it’s not EVERYTHING that’s broken, or not EVERYTHING is enhancement-prone.” Typically, if you think about the 4/50 rule, maybe one module out of 25 encounters a lot of maintenance because it has too many bugs or something like that. If you just go in and rewrite that one module to make it error free… gosh, that would clear up a lot of problems. And then there’s one module out of maybe 25 that is enhancement-prone, where you’re always changing it. Maybe there’s some way to put all that data out in a table so that you change the table and not the software all the time.

“We have some things that need maintenance and some things that need enhancement, and if we make those two things work well, the other 23 modules are just fine. They’re just going to be just fine. We don’t need to rewrite all this software all the time in a new language and… , you know… Programmers want to rewrite things because they don’t want to have to fix the stuff that somebody else wrote, which is kind of foolish. Even in the QI Macros, there was one piece of code that was giving me trouble and I had to rework it, and one that was more enhancement-prone and I had to rework it to make it more easy to enhance. Now that’s gotten out of my way, so I don’t have those problems any more.

“I’m going to tell you no matter what kind of software you work with, you don’t have to rewrite the whole thing; one out of 25 is causing most of the headaches and bugs, and another one out of 25 is having most of the enhancements. Just fix those pieces and move on.

“I’m Jay Arthur. That’s my Improvement Insight for this week. Let’s go out and improve something… maybe some software.”