Saturday, November 2, 2013

The software developer's fallacy

Wow. Very long time to go without updates.

I'd like to rant a bit about how a lot of software developers are being sort of stupid in how they go about their profession.  This may upset some people, that is fine.  Please leave an enraged comment below.

Let's assume that deadlines are tight, because that's just the industry and deadlines are always tight.  You need to get a lot of work done in a short time.  Do you opt to:
  1. Working overtime, stressing and drinking bucket-loads of coffee
  2. Cuting corners and skimping on best practices
  3. Cutting unit tests / foregoing code maintenance
  4. Some/all of the above
  5. Proceeding at a normal pace
A vast number of software developers will choose option d.  I will argue that this option is only correct if your job is letter-entry.  That is, what is bottle-necking your productivity is how many keys you can press in a given time-span, and the time you spend debugging and analyzing problems is insignificant compared to the time you spend mindlessly typing code.

Fig A. A hypothetical work-distribution where entering code is the most time-consuming activity.

Let me tell you, this is very foreign to how I work.  Maybe COBOL programmers had this type of work-distribution?  While I may hammer away at the keyboard quite a lot, it isn't my main activity.  My main activity is problem solving. Pulling numbers out of my ass, I'll argue that the distribution in figure B is a lot more accurate.

Fig B. A majority of time is spent problem-solving. Entering code is big, but not the major activity.

Let's look back at the approach programmers take to meet deadlines. Options b and c--skimping on good practices--emphasizes a reduction in key-presses, at a cost of code quality.  It increases the time spent debugging the code, if not this sprint, then certainly the next one.  Having poor test coverage means debugging takes even longer time, and re-factoring is nigh on impossible, so even the mindless code-entry part will eventually start to take longer than it necessarily has to!

If code-entry is indeed a major bottleneck, there are better ways of changing that. Setting up some eclipse templates for boilerplate goes a very long way.

Cutting corners seems like a poor strategy, so what's left? Overtime. If it is an occasional occurrence, I'm all for it.  But chronic overtime is counter-productive. Innumerable studies have demonstrated this[1]. To make matters worse, most of the developer's time is spent thinking, it should be fairly self-explanatory that this is not the type of work that benefits from an exhausted practitioner.  Among the most time-consuming activity in software development is fixing bugs, and developer exhaustion is a significant cause of these bugs.  Therefore, increasing exhaustion increases the time it takes to implement a given feature. You can actually end up producing less than you would, were you working normal hours!

My thesis is this: It is flat out counter-productive to rush software development.  You are spending more time producing less, at lower quality, than if you simply play by the book and let the development take its time.

Other craftsmen have had this figured out for ages. It's time we did too.

Measure twice, cut once.


Correcting mistakes is among the most time-consuming aspects of software development, which is why preemptively avoiding them is arguably the best way of meeting the deadline, even if it feels like you are "wasting time". 

The bottom line is that you have ample time to type almost any code into the editor this sprint (along with ample unit tests).  What will make or break the deadline is how much time you spend debugging what you entered.


[1] http://cmdept.unl.edu/drb/Reading/overtime2.htm

3 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete