I didn’t have enough time

“I really didn’t have enough time for that…” — this is the most frequent excuse used by programmers for writing messy code, skipping refactoring, not writing unit tests etc. This is a poor excuse and there are at least two things wrong with it.

The first one is the unstated assumption that writing clean, tested, extendible code takes some horrible amounts of time (as opposed to writing quick & dirty code, which apparently takes no time). This is not true and I’m not the only one that thinks so. Of course, if you’re totally new to writing high quality code, it might take you some time to get fluent with it. But in this profession, you should be constantly learning anyway.

Also: if you take technical debt into account, you will see that writing high quality code is faster in the long-term because there will be less bugs, new features can be implemented faster and new developers can be brought in without extensive training.

The second thing wrong is the psychological aspect. In most cases it’s the developer that estimates how much time is needed for implementation^[1]. So the question is: why don’t YOU include in your estimations the time needed to do it right? If implementing some feature right would take 5 days (because you know that this specific area needs heavy refactoring), why do you say “2 days” instead? Are you afraid of saying “5 days”? Is somebody going to fire you for that? Unlikely. Shout at you? Also unlikely. Can’t you stand a little shouting, anyway?

[1] I worked at several companies, from 3-people startup to large software house, from bank startup to global corporation, with wildly different methodologies and tools, and had not seen a single case when the developers were held responsible for estimations done by someone else.

My advice: estimate the time it would take if you would do this the best way you can imagine, including good design, the long overdue refactorings, unit, functional and integration tests (as needed), documentation and everything else you consider makes code better. And then stand for it. Fight for it, if you think it’s worth it.

But only if you really want to do all those things, that is, because the problem might be that you think they would be nice but are too lazy to do them. Maybe you don’t fight for it because you’re happy with the way it is and don’t care about your project’s future?

Of course, your estimation might be questioned (“why do you need so much of time for something so simple?”) or your manager might argue that “maybe you could do it in half that time” or “the CEO will be very upset if it’s not working by Friday” or “we have already spent a fortune on the advertising campaign, so there’s no way we can postpone the deadline” or the customer won’t stop haggling with you to do that in half time and for half pay. Life is brutal, or so they say.

Do you really think your Pointy-haired Boss will tell you “I want you to take 3 days extra for refactorings”?

If you are questioned, explain what it takes to write good code, what the technical debt is, how clean code makes the development faster in the long run etc. Why do you expect your manager or customer to know what it takes to write high quality code and why it’s better for them? You need to educate them.

Make your manager understand the risks so they can make an informed decision. You might be forced to skip some of the elements anyway and finish sooner, but at least you will have higher margin for negotiation. It’s OK for me to take shortcuts if I know that my manager is aware of the risks, we feel the technical debt is under control and the situation is exceptional.

Similarly, if you’re in the startup, struggling to get the first version out the door with competitors breathing down your neck. Go ahead and take every possible shortcut to make it ready ASAP, I’d say, but be aware that you’re building the technical debt and you’ll have to pay it up sooner or later. That’s why many successful startups go through complete rewrites of their applications at later stages, I think.