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.

Pointy-haired Boss

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.


4 responses to “I didn’t have enough time

  • paul

    correct. i completely agree.

  • Christian

    I’m sorry but you’re wrong, copy/paste coding is much faster than anything else and it’s a bad practice because of code duplication. It takes more time in the long run to maintain it, but in the short term it’s much faster to copy something than it is to write an entirely new piece of code.

  • szeryf

    Christian, I think you didn’t read my article thoroughly. Your comment summarizes what I think on writing good code vs bad code. If I’m wrong, you are, too :)

  • John Feasible

    Unfortunately, release cycles may not allow for the refactoring that may be necessary to make the end-result clean and highly maintainable. For example, if I am expected to develop four new features in three weeks. It may be that one feature would require two weeks in order to get “right” (with a refactor), but that will not leave me enough time to develop the other features (which may be on a roadmap for critical strategic reasons).

    A lot of companies, unfortunately, would require for all the features to be developed and meet functional specifications rather than for 1/2 of them to be implemented exceptionally well.

    Personally I’d love to work for a successful company that doesn’t have this mentality.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: