Getting a program done sooner – Part 1 (the wrong way)

In my career, on more than one occasion, I have found myself in a situation where someone wanted me to complete my work sooner than expected.  In programming, most things just take some time.  It is okay to ask a developer to work harder or faster, but for people like me, it isn’t likely to really result in much of a difference.  It is not because of my attitude.  It is quite the opposite.

The reason that my work cannot really be accelerated, stems from the fact that I truly love programming.  Because of my love for programming, I program my heart out.  I always do.  It is fun and I love doing it.  Think of it like this:  When you love something, do you savor it, or do you fully apply yourself and before you know it, the job is done? For instance, in my house, a bowl of French onion dip never lasts more than 5 minutes (once my kids find it).  Savoring it would take a lot of self-discipline.  I guess I could do that with programming, if I really tried, but I usually only slow-things-down when it produces a better program and not just for my own enjoyment.  Most senior software developers are probably like this too.

Need for speed

When I think of “going faster”, my mind turns to auto racing.  People who are unfamiliar with auto racing will watch a race and wonder why the slower cars aren’t just driving faster.  “The gas pedal is on the right!”  In reality, the slow cars are usually going [as fast as they should], not [as fast as they can].  It is not a matter of pushing the gas pedal harder.  This is because, when the car goes too fast, it will not be able to turn left, to avoid the walls. Yes, tire traction is a big limiting factor and you might not be aware of it, because as a highway driver, you almost never have to be concerned with it.

A better way to increase the speed of a race car, is to ask the driver what can be done to make the car faster.  Then, he will probably talk about things like { steering geometry (too tight/too loose), engine response, tire pressure, aerodynamic effects like downforce, trimming weight from the car }.  Anybody who is familiar with auto racing will agree. The problem is not solved at the gas pedal.

It is the same for programming.  Except, [programming too fast] won’t result in a broken computer, but it is probably going to be a broken program or server.  When a programmer rushes to get a program done, he is going to overlook subtle details, and leave-behind flaws that otherwise would have been caught.  You are better-off asking about the programming equivalent to { steering geometry, engine response, tire pressure, etc. }

Short-Term Gains

I guess some people don’t worry about a broken race car or two.  I’ve watched NASCAR races and some of those guys will wreck a 1/2 million dollar car and say “Well, that’s just racing, I guess”.  It is a little hard to imagine.  Personally I think my head would pop, if somebody borrowed my own humble commuter car and wrecked it.  I can almost imagine the impolite things that I would say.  Eventually, I would cool-down and impart some words-of-wisdom, like “you are better-off arriving a few minutes late, rather than not arriving at all”.  Maybe I’m just overly safety-conscious or something.  Somehow, wrecking a car just doesn’t seem worth-it to me.

Maybe you disagree, because you are a disciple of “the NASCAR way of doing things” and so, your definition of “done”, might be quite different from mine.  In that case, your developers are expected to wrinkle some fenders, trade some paint and get their programs done a little sooner than expected.  For instance, you might be the kind of person who would find the following options, acceptable:

  • Accept a lower-quality outcome (more bugs, incomplete features)
  • Cut features (less work to complete = done sooner)
  • Borrow from tomorrow (sometimes, you can do some tremendous corner-cutting in trade for minor schedule gains.  It is never worth it.)

Honest Gains

Most people would agree that these ideas (above) are generally, terrible choices, but there are harrowed managers who pick from this list periodically.  If you want the impossible, then you might resort to cheating (eg. picking from the above list).

Let’s just assume for now, that you are not willing to gamble with low-quality and you are genuinely interested in optimizing the throughput from your programmers.  So, let us consider a deeper question: what can be done to get more output or productivity from a typical programmer?  Like in auto-racing, is there something that can be done, beyond simply pressing the gas pedal harder?

The Simplest Approach(es)

Consider the metaphor of optimization as it applies to other fields, such as server optimization or app optimization.

For many managers, the simplest and most obvious solution is the ole “ask a programmer to simply work more hours”.  This strategy is akin to overclocking a server.  It is very easy to over-clock a server and see a meager gain.  This will produce a meager gain but it also increases risks.  When the server is overclocked, it is running hotter than the manufacturer intended. This will shorten the lifespan of the equipment.  Also, pushing this too-far, will result in broken equipment.  Instead of faster results, you now have no results, plus a bill to replace the equipment.

A risky trade-off for a narrow ROI, is not a good plan.  Hopefully, you don’t have to learn this the hard way.  Labor laws were made because the productivity (and even health) of a person, will diminish after 40 hours/week of work.  Ten hours of overtime from an exhausted developer is really only as effective as four or five hours of normal time.  It also begins to subtract from the other 40.  Basically, you are wasting his time and yours.  You will “break” the programmer by increasing his “flight-risk”.  If he gets sick or gets fed-up (and leaves), you will end up further behind as you try to find a replacement.

Okay, I’ve talked about a lot of things that don’t work well. Don’t lose hope. In part 2, I will talk about the things that actually will work.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Lessons Learned, Methodology, Optimization and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s