Improvement Insights Blog

I’ve been building software for over 50 years. There are some secrets to software quality that are often overlooked. Here’s a few:

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

“I’ve spent almost my entire life working in software and software development, from mainframes to minicomputers to microcomputers, ultimately leading to the QI Macros. I’ll tell you what, I took a course a long time ago from T. Capers Jones where we studied what makes software maintainable and unmaintainable. It turns out how many decision points you have in a given module determines how testable and maintainable it can be. Guess what? Back to seven, plus or minus two… so about nine or ten. Once you get to ten that module becomes untestable.

“Now I brought all this wisdom back to the phone company and there were some guys in the billing engine who thought I was out of my mind. They had this one big 25,000 line COBOL monstrosity that was the rating engine for all the phone calls and all the other stuff in the phone company, and it was a giant unmaintainable thing. They decided to prove that I was wrong and so they took this thing, they split it out into three main pieces, right? Sort of one that drove it, and one that did this, and one that did that… and a shocking thing happened: The thing became infinitely more maintainable and they had to admit to me they were wrong. One guy, Jim Dimino, admitted “Uh… you were right,” but they had to go prove it to themselves that I was right. Invariably, when I’m working on QI Macros I’m trying to keep all my little modules down under 10 decisions.

“Now there are certain kinds of things that I’ve found are common mistakes in manufacturing (not manufacturing…) in software. One of the most common is an “IF / THEN / ELSE”, so if I say something like “IF a = b, THEN c = d.” Okay? But one of the things that I very often see is a piece of code like this but what’s missing is the ELSE. Very often, because there is no “ELSE,” when you read that you don’t think about what else could go on, right? So maybe there should be something here. Now maybe I just put in a little comment or something and just “comment it out,” or perhaps there’s something else like “d = e.”

“This invisible chunk of missing code causes lots of problems. It’s bit me more than once, and so there are certain kinds of things in software that can be set up so that you mistake proof it. Now if I code an “IF,” I put in an “ELSE” even if it doesn’t do anything, because next time I read through I [see] “IF / ELSE” and I [think] “Ooo, ah! There’s something else going on here.”

“So get this idea that we can take what we learn from how software works, even: defects, right? Errors, mistakes, things that go wrong, programs that blow up, all that stuff… and we can use Six Sigma on that too.

“That’s my Improvement Insight. Let’s go out and improve something this week… maybe even software code.”