Why is programming so hard??

9 November 2014

Tom Breur

“It surely can’t be that difficult?? Could it?” Does that sound familiar? Does your management ever get impatient with you? When you get down to the nitty-gritty details, even seemingly simple jobs sometimes take (a lot) longer than you’d expect. And what is worse: they typically take (a lot) longer than management would have hoped for.

We sometimes talk about inherent and accidental complexity. Inherent complexity comes from a problem being genuinely hard to solve. Some people talk about essential complexity. Despite efforts at simplification, filling out a tax return can be hard in some situations. I’m impressed, for instance, by how easy TurboTax makes my application look. But at the same time I can appreciate the many heuristics and loops that must be running in the background.

Accidental complexity is sometimes referred to as “technical debt”, and other people talk about incidental complexity. But first I’d like to make a point that there is a fundamental distinction between conscious and unconscious sources for poor code (be they one or the other).

When you (deliberately and consciously) choose to deploy suboptimal products, apparently there is a perceived need to go to market in a hurry. If the urgency is high enough, you may choose to pay the price for this. That scenario signifies “technical debt”, I would say, because you deliberately choose to incur it.

In practice, however, I think that many instances where we talk about “technical debt”, the poor code we’re referring to was not the result of expedited releasing. The code fails to impress because of either modest skills or a lack of understanding, but there might be more reasons. A generic term would be “sloppy code”, to indicate its inherent shortcomings.

In general, I personally like to talk about “lack of craftsmanship” to circumvent any discussions whether the general lack of quality was intentional or not. When you take a look at source code sometimes, words like “spaghetti” come to mind. It’s the kind of complexity that could have been avoided. But only if we had more time, more money, or if we were more skilled at our jobs.

Many people I work with are (like me) eager to deliver great products. As quick as possible, with the highest possible quality. Needless to say that means you have to make tradeoffs, because good is the enemy of better. We may have been using the wrong tools, but changing that would have taken a lot longer. So we release anyway. We know there are patterns we can factor into the code, but we “don’t have time.” Is that technical debt? Or general sloppiness?

To some extent the discussion what is and isn’t technical debt is a moot point, since we need to deal with the end result in much the same way. As long as we are aware that there is a legitimate distinction between releasing “too early” for a variety of reasons. And as long as we are aware that you can always improve your skills to avoid some of this unnecessary complexity. What are you planning to do in the short term to grow your skill set?