Developers create things. Most people know that. What only developers (and by extension, the people who manage developers) know is that developing is a constant struggle against the Scales of Estimation.
Let me elaborate: whatever the current task is, a developer always has to ask herself; “What do I need to do and how much time will it cost me to do it properly?”. Properly is the keyword there. For any given task there are very different levels of done. You might solve a problem by the equivalent of using duct tape to make sure something doesn’t catch fire, but if you do so the duct tape will probably instead start leaking water after a while. Quick solutions are just that, and it’s only rarely that they don’t cause other more severe problems down the road.
The problem is of course; who has the time to do everything properly when there are a thousand pressing tasks to be done?
(sadly, that “everything” is often more in lieu with “anything”)
Coming from the startup world, I’ve been beating around this quite a lot. The entire software development community is currently obsessed with the agile trend, and the world of startups is almost doubly so. And for good reason; for startups every day is a battle of sink and swim. If the developers don’t churn everything out at maximum pace, the ship will most certainly sink.
Of course, time is not the only factor. Everything needs to be perfect, stable, tested, documented and scalable as well. As the saying goes: “Fast. Good. Cheap. Choose two.”
Luckily, as with most things in this world, these are not absolutes. This is where the skill of the Scales of Estimation come in. Whenever we developers do something, we can balance between doing something quickly and cheaply or doing it properly and sturdy.
I can honestly say that this skill is the one I try to hone the most. It is one of the ones I value most as a developer, and simultaneously the one I’m probably the worst at. It’s just very difficult to do it right, most probably because every situation and every task need their own estimation and because so many external factors may or may not affect the decision and the outcome.
I just always try to remember:
“Whenever you do a quick fix, you’re just borrowing time from your future self.”