meaningful software: quick-and-dirty bias

A quick and sad note:

In the competition over the amount of biases, software development would come second after politics or parenting. The quick-and-dirty bias is one of the many.

It is both pretty specific and very common: just write the code as quickly as possible, don’t waste time on making it clean — just deliver as soon as possible.

Any software engineer who worked on a sizeable code base in a team where developers come and go knows that the quick and dirty code turns into matter of painful nightmares in a couple of months if not sooner leaving trail of incomprehensible mess, constant crashes, debugging, rewriting, and generally massive drag on development — one can fill a few bookshelves with books on the subject written over half a century.

Even so, there are well-known clean lightweight methods to contain quick and dirty code. The problem is that “clean” becomes a dirty word for the bosses who ask for quick and dirty code.

When presented with the alternative: how about I write quick and clean code instead (which I just know will take the same amount of time)? — their logic goes: if quick and clean code takes you a week, just don’t do it clean - dropping clean and doing it dirty somehow will take you a day.

It is a causal fallacy. What your boss probably means is “do as little as possible”. He just needs to somehow believe that “clean” precisely means “as little as possible — but not less” and trust you on that. But he won’t.