In programming people sometimes feel they have to sacrifice quality in order to get a product out the door on time. Never do this. You are hurting the customer, the company and yourself if you do.
This American Life had a very interesting program on the New United Motor Manufacturing Inc (NUMMI) plant in Freemont, California. NUMMI was a joint venture started in 1984 between Toyota and GM for both parties to learn from each other. GM would learn about Toyota’s quality control systems and Toyota would learn about building cars in America.
The amazing story is the turnaround of the plant. Prior to the joint venture, the plant was operated by GM and was one of their worst factories. The program talks about workers gambling, having sex, and drinking at work. They produced very low quality cars and didn’t really care. The plant was closed as a result. However, for this joint venture, GM agreed to re-open the plant and hired back many of the original workers. Thanks to Toyota’s quality systems, the plant turned around to become one of the best GM had.
One example of change was “stopping the line.” The GM workers grew up with the notion that you don’t stop the line. If you notice something is wrong, you just keep it going. Just get the cars out the door. With Toyota’s system, workers were encouraged to stop the line if they noticed something wrong and fix it on the spot. This was a big shift for them. The process became about quality over quantity. Within just three months, cars coming off the lot were being made with near perfect quality.
When you let an error slip, either with cars or with software, you are compounding the problem. It takes much more time and money to fix the problem later than when it is first discovered.
How much more money? One study estimated “it would take 50% more workers under the old system to produce the same car.”
Recently I had a situation like this. I was responsible for checking over and delivering database scripts to a client. I noticed one of the scripts had an input parameter and while I got a feeling I should double-check about it, I ignored that intuition and delivered them anyways. The client ended up running the scripts in their environment but ignored the input parameter which caused part of the scripts to fail. There was a lot of back and forth to get it fixed. I estimate it probably wasted about one man-days worth of everybody’s time. Because I didn’t take 5 minutes to check about something that could be wrong, I ended up costing hours worth of time.
It’s not mentioned explicitly but it is implied that the vices went away after the quality program was introduced. While workers were embarrassed to be working at the plant before, they now were proud to tell friends where they worked.
In ancient times, brick makers, engravers, and other artisans used a symbol to mark the things they created to show that they were the makers. The symbol that each one used was his “character.” The value of the work was in proportion to the skill with which the object was made. And only if the quality of the work was high was the character esteemed. In other words, the quality of the person and his work gave value to his credentials. If the work was good, so was the character. If it was bad, then the character was viewed as poor.
– “Becoming a Person of Influence” by John C. Maxwell & Jim Dornan
This is why the morale and esteem of the workers improved once quality became the focus. Your character is revealed in the work you do and vice versa. If you are producing shoddy work, your character is being revealed as such.
In programming, quality does not mean taking a stand over something trivial such as whether to use tabs or spaces for indentation. Quality means being consistent in your work. It means following design principles that will save time and effort down the road. It means doing things right the first time so you don’t need to correct them later.
Always do things in a quality manner. Never compromise. For if you do, you are compromising your character.