The future is now

You know what future is now? The one you mentioned one month ago, when you said “let’s copy and paste for now and fix it in the future.” And the one from “we’ll add unit test for that in the future.” And when will this “later” from “we’re going to refactor this later” happen? Later, of course.

Your “now” is the “future” in which former developers hoped to find some time and fix all the problems. They never did, of course, and now you are pushing even more into the future, for yourself or your successors. It’s like taking a huge debt intended for next generations to pay up and then taking even more debt just to pay the interest. It’s like a Ponzi scheme in development :)

If you always decide to cut corners “now” and fix it in the “future”, that future never comes. Instead, you’re setting yourself up for the future of constantly putting out the fires and wondering why your application cannot be more stable.

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.

Does stubbing make your tests brittle?

Stubbing and mocking in unit tests is generally considered a Good Thing. It can make your tests run faster, it helps you not to cross boundaries. But it also makes your tests more brittle.

The reason for this is simple. If you want to stub out some method, you have to do it very precisely. You have to know the underlying implementation and choose a very concrete instance and method for stubbing. This makes your test very tightly coupled to the implementation details of tested class. And tightly coupled is brittle. Let’s look at some trivial example:

Unstubbing methods in Mocha

Recently I needed to ‘unstub’ a method in Mocha. Browsing Mocha documentation and googling yielded no results. Apparently, Mocha doesn’t support a concept of ‘unstubbing’, i.e. recovering original implementation of a method that has been stubbed. After a little hacking, I found out that it’s quite easy (though not necessarily elegant) to call original implementation.

Make your tests run 25% faster

How?

By turning off the use_instantiated_fixtures feature.

But why?

Because they’re slow! Didn’t you read the comment in your test_helper.rb? Yes, this one:

# Instantiated fixtures are slow, but give you @david where otherwise you 
# would need people(:david).  If you don't want to migrate your existing 
# test cases which use the @david style and don't mind the speed hit (each 
# instantiated fixtures translates to a database query per test method), 
# then set this back to true.

But what about those nice @david variables?

They must be gone. Sorry. The tests are slow because of them. The above comment explains why.