Process Improvement

I used to think Process Improvement was a meaningless buzzword phrase.

On more reflection, most buzzwords generally seem to come about because of a good idea however that good idea gets lost when people don't understand the core idea. They try to slap it on like a band-aid and put some semblance of the idea into practice.

For instance, with process improvement, it is easy to say "Checklists improve performance, therefore let's make lots of checklists and force people to use them". Another example would be "Statistics help us understand what we're doing, so let's go get tons of statistics."

What it really all comes down to is quality. We want to improve quality and or maintain costs. This improves the value of whatever it is we are working on.

In my job I have implemented some checklists in my programming routine. Every time I get a new assignment I create a workspace, a set of other checklists, a design document on the wiki, a test plan on the wiki, a notes file, and I take control of the assignment. This helps me get organized and guarantees that I approach every problem consistently. I am programming myself to respond to a common problem with a good response.

My boss gave me a performance review last year and one of the things he mentioned was a problem I had been having with a certain aspect of coding. I was occasionally leaving debugging information in the code. This is sloppy for a number of reasons that I won't go into.

I now have two new checks in place in my checklists because of this. I check the file diffs and I rerun the software immediately before committing it to version control.

So, I made a checklist. The checklist itself didn't help me, it is that I have the right checklist. How did I make the right checklist? By using feedback from my boss. I'm making a specific change based on a specific problem. The issue I see in plenty of places is that people implement broad shotgun-like changes and expect that to fix everything.

Specific issues I have fixed:

I never send out an assignment without a test plan. The solution was to always create a test plan before starting work on the code. Specific problem. Specific solution. This helps in so many other different ways.

I never send out an assignment with debug code still in it. I'm proud to say that since my review last year I have had no assignments returned because of debug code. The process works. Put in the checks and force yourself to obey them. If you don't rigidly obey the checklist you might as well not have it. It definitely makes things slower, but it improves quality and that is worth the tradeoff.

I will occasionally spend 30-40 minutes setting up everything for an assignment only to spend 10 minutes researching the problem to find that the solution is something as simple as retranslating a file. It sounds like I wasted 30-40 minutes doesn't it? However the time I save in all those other cases where by habit I've ingrained this discipline more than makes up for the time lost on the rare easy assignment where the checklist is overkill.

In the end my opinion from the last year's work is that rigid adherence to quality control wastes time in the short term sometimes, but in the long term it pays large dividends.

No more having to read assignments again a month after working on them because I didn't write a test plan when I wrote the code.

No more having two or three extra revisions causing version control conflicts because of left in debug code.

No more searching through unorganized text files for information on an assignment's progression. Just look at the checklists and you can know what stage it is at.

While "work smarter, not harder" can definitely be an over repeated, nonsensical phrase for some people you can actually improve your work process. It requires critical thinking to identify weak points and coming up with solutions that can be easily implemented. A thorough systematic approach is the best way to improve your quality of work.

Analyze Thoroughly.
Document Specifically.
Implement Consistently.