Tipping the Scales

November 10, 2008
Add Comment

Every organization needs procedures. What needs to happen when I file a bug? How do I notify clients that their feature is in production? Who do I bill this work to? All of these are simplified by procedure. Instead of having to figure out the issue and devise a solution every time the problem arises, procedures allow us to base our actions on past thought and designs.

Procedures can be good but they can also create more problems than they are worth. When procedures reach a point to where you are spending more time trying to find the right procedure than you would if you just figured out the problem from scratch, they are a burden.

A happy medium should be targeted. This middle ground should ultimately save time – otherwise it is a wasteful venture. If you have to spend long amounts of time searching for or through documents just to figure out what is supposed to happen then the system is a failure.

Next time you are going to add a procedure you should stop to ask yourself the following:

1. Does this solve a tough problem?
Does this procedure save people an inordinate amount of time or money? Does this procedure address an issue that is difficult to figure out on a case by case basis? If either of these are true then the procedure is likely to be a good addition.

2. Is this going to simplify things or add undue process?
Will people have to take a lot of extra steps just for the sake of procedure? If any part of the procedure is there just for the sake of it and doesn’t produce a tangible output then the overall process is diminished.

3. How easy will this be to remember?
If a procedure is hard to remember then people will need to look it up each time. This, by itself, doesn’t necessarily negate usefulness. However, if people have to look it up and it is tough to find then the process becomes much less useful and less likely to succeed.

4. How often is this likely to happen and what is the importance when it happens?
If the item in question rarely happens and/or doesn’t have a lot of value associated with it then there is likely not a need for detailed procedures. For example, declaring war doesn’t happen that often but has a high cost so a procedure is needed. Conversely, working showstoppers happens far more frequently but has a relatively low cost.

Book Review: Code Complete

October 18, 2008
2 Comments

Code Complete: A Practical Handbook of Software Construction, by Steve McConnell

51jokj0md0l_sl500_bo2204203200_aa219_pisitb-sticker-dp-arrowtopright-24-23_sh20_ou01_.jpg

This was a great book. If you have been in software for a significant time you are likely to have picked up many of these habits already, assuming you have been around experienced engineers who have helped you cultivate your software capabilities. It is chock full of useful information that every engineer should know. While this is a sure career improver for new engineers it has information that could easily be digested and used by even the most experienced programmer.

Seminal book. Buy it.

Over the code

October 17, 2008
Add Comment

I realized a while back that I have grown tired of writing code. I still enjoy the design aspects of software and enjoy being involved in the software creation process. I just no longer care for the implementation aspect of the business. I haven’t written a line of code in probably three months. I haven’t written a significant portion of code in at least six months. And I’m happy.

My parents were both programmers so I got a very early introduction to software. I began by writing little programs, address books and the like, throughout childhood and high school. I then jumped into a data entry job, which I quickly figured out how to write a script to help automate. From there I never had a job where I didn’t write code. Until now.

My parents both ended up in management – my Dad has relatively recently returned to writing code. They both told me the same thing at one point or another: they just got tired of writing code and wanted something new. I believed them and figured that I would follow suit sooner or later.

About five years ago I was still pretty into writing code still but looking to the future I saw myself growing wary in the next five to seven years. My timing ended up being just right. About five years ago I started getting into more leadership roles – leading software teams while still having my hands in the code. Over that span I have slowly become more and more removed from the code until just a few months ago when I decided I was completely done with it. I am now in a role where I don’t write any code but still have a high level of involvement in the design and development processes.

I may still write about code and software practices here and there however, as is obvious by my post trends, they will become less frequent. I imagine that the main focus of my writings will continue to be business of software and economics, with a little bit of software sprinkled in here and there.