The MurkyGrey blog

The difference between amateur and professional software development is, I am told, process. Tedious, endless, creativity-stifling, headache-inducing process. A bunch of rules that developers hate and ignore, while development managers bite their lips and try to enforce.

Software development, like many other technical undertakings, requires a combination of creativity and discipline and it is rarely successful unless both are present. You may choose to only hire highly creative and extremely self-disciplined developers. If you do, please let me know how that is working out for you… I’m not saying that these people do not exist, they do, and they are spectacular, but they are few and far between and if you hold out for them your staffing efforts may take longer than expected. For most of us there is a conflict between being creative and being disciplined and we struggle for balance. So there you are with a team of creative developers who are not crazy about rules.

Early in my programming career I was part of a maintenance team. Our job was to fix bugs in the live product while the product development team worked on future releases. I learned a lot about good and bad code, and about how good code can be turned bad by a series of undocumented changes. When it’s new, good code is coherent and consistent, it is readable and it makes sense. But code that has been around the block and back often becomes a jumble of changes made by different people unaware of each other. This degradation can be mitigated by documenting changes. Back in 1993, the rules stated clearly that each change must be documented in the source file’s header. It’s good process, but it was almost never followed. Enforcement (via code reviews) helped some, but the team did not seem to have the degree of self-discipline required to eliminate the problem completely. Then one day the problem was eliminated, not by better enforcement but by the introduction of a tool: a new source control system was put in place that required a comment on each change and inserted the comment into the source header. People still could write a non-comment such as “NA”, but nobody did. Instead, every change was accompanied by a good, descriptive, useful comment.

Process was followed at last. Changes were documented and code integrity was protected. Best of all, our manager didn’t have to harass us to do it anymore; we felt more independent and he had no complaints about the new order of things either. Code reviews, now free from process enforcing micro-management became positive educational experiences allowing us to learn from each other.

The tool (in this case the new source control system) did two things:

1. It provided people with a ‘just-in-time’ reminder to follow process. When you were done making your change and you wanted to push it to integration testing you had to check it into the source control system. That was part of your job, you had to do it anyway. While you were there, the dialog popped up and asked you to put in a comment and you did. The burden of remembering the rule had been lifted from your shoulders.

2. It took away the tedious, mindless task of taking your comment, adding date and time and pasting it into the right place in the headers of several source files. You were left with the meaningful task of writing a paragraph to describe your change, the rest was taken care of automatically.

I’ve seen the same thing happen with other process-related tasks. Collecting timesheets was always a painful and frustrating task until I had a system in place that sent email reminders with a “report your hours” link in the message. Logging hours was never hard, the painful part was remembering to do it. With an automated reminder that puts you a click away from completing your report, the pain is gone and process is followed smoothly and effortlessly. Similarly, testing and verification procedures were a real PITA until issue tracking systems with built-in workflow management came along.

No matter how lacking in discipline you think we developers are, what we really hate is having to remember tasks that are not directly related to coding. We also dislike mindless repetitive tasks that we know should be automated. Micro-management is bad for us and bad for our managers, give us a tool for every rule and process nirvana will follow.

Do rules drive you crazy? What do you do to cope with process? Leave a comment.