Category Archives: TDD

I got a very interesting comment from Rick Pingry and I’m taking a liberty to respond to him in the post format, because I think his questions deserve so. In general, Rick expresses his doubts about going TDD all the way and raises some really good questions about practical side of TDD. What’s interesting (to me at least) is that he works on a C++ application, so it’s good to hear that even the C++ world is catching up with some modern trends :)Continue reading

“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 onethatthinksso. Of course, if you’re totally new to writinghigh qualitycode, 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.

I’m sick of hearing the same old song again and again: “we wanted to try TDD but it would make us go slower, and we wouldn’t make the business friendly deadlines so, you know, maybe next time”. This is bullshit. A myth. An urban legend. Not true. The truth is just the opposite: TDD makes you deliver faster. How can this be?

Well, it’s true that TDD makes you write more code than if you wouldn’t write automated tests at all. But, anyone who knows a little bit about programming will tell you that actual banging at the keyboard (i.e. writing or editing code) takes only a small fraction of programming time. Of course, this varies between developers and, of course, I didn’t measure it, but I’d estimate it to take only 10% to 50% of productive time (i.e. not counting the time developers spend surfing the net or attending the meetings).

All of the rest is consumed by various coding related tasks: thinking, designing, discussions, brainstorming, committing to the repo or updating from it, waiting for the code to build and/or compile (optional of course), digging through the docs, browsing help and forum sites.

And, if you’re not practicing TDD, you also have to waste a lot of time on debugging the application, manual testing (restarting it, logging in and navigating to the screen on which you can observe the effects of your changes to the code (again, optional), and fixing the regressions you introduced (not all though — only those that you noticed (and chose not to ignore) on your way to the above mentioned screen).

So, instead of wasting enormous amounts of time and effort on manual testing and debugging, the effects of which vanish into thin air with the next line of code you change, why not start writing automated tests and have these same tests executing over and over, automatically, for the project’s whole lifetime?

And one more thing about debugging: while working for 2,5 years with Ruby on Rails projects that have been done with TDD and/or had high level of test coverage, I hadn’t used a debugger. Not even once. Unbelievable for Java folks, but true.