The One Thing Every Software Development Manager Should Know

In light of Jeff Atwood’s recent post on the one thing every software developer should know, I immediately had to think about the one thing I believe every manager involved in software development project should now. Namely the law of the Four Variables in Software Development.

Now before I’m going into the details, first I will shortly break one of the cliches of blogging: “don’t apologize for not writing for a certain time”. Well, actually, I won’t apologize, but I do have my reasons for not posting in the last couple of months. I did write about my job change before code-muse went black for a while. Almost all my time got sucked up by working for my new employer. I traveled to California for training sessions and getting to meet my colleagues overseas, and besides that, my daily commute time increased significantly compared to my previous job. For that same reason, I’ll be moving this December. You can already guess that finding a new house took a bigger part of my free time as well. Fortunately, everything is slowly rolling into the right direction now, and I finally had some time to not only start reading my favorite blogs again, but also start writing again.

Back to that one thing that every manager that is controlling something software development related should be aware of. Namely, there are four important variables in software development: Functionality, Quality, Time and Resources. Now here’s what you should stick in your head forever: you cannot control all of these variables simultaneously. So whenever you hear yourself saying: “I want this functionality with these resources, at this level of quality, and I want it done by the end of…”, stop at that instant and write down “I cannot control all the four variables functionality, quality, resources and time at the same time!” a 100 times. And the next time your punishment will be bumped to a 1000. When you end up writing that same sentence for over a million times, maybe you should start thinking about a career move.

A clear, concise and detailed description of the four variables I found in a paper written by Richard Blouin. The article cleanly describes the aspects of fixed and free variables in different circumstances. In practice, I believe almost all programmers who have participated in a smaller or bigger (business) software development project know that however being fixed, in the end, one of the four variables will always end up being a free variable. In my past experience I have seen that quality is sacrificed in many cases. But also time is a popular variable to end up being free. The worst cases are those where the release date is fixed — and one is supposed to believe that time is thus fixed — while time remains a free variable, in the sense of the amount of time spent on development. This usually has the side effect of quality dropping at the same rate as time is increasing.

More than once I have come across the following quote, which I think is the most earthy way to describe this concept: ((I do not know the source, and to be honest, I am too lazy to research who said or wrote it for the first time.))

You can either have it [1]:

  1. Good
  2. Fast
  3. Cheap

Pick two.

[1]Note that this particular quote assumes that functionality is fixed.