The Duct Tape Programmer

can we have the link updated?

when I was linked from my rss reader (just now-ish), it was set to go to: http://localhost/www.joelonsoftware.com/items/2009/09/23.htm...

should be: http://www.joelonsoftware.com/items/2009/09/23.html

thanks.

I work on enterprise software in a financial company, and IMO, this quote from Zawinski would lead to a dangerous short-term view in that context: "unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that."

When you work in enterprise software, this approach might work on the first project, maybe the second, but eventually a point will arrive where a requirement will take longer to deliver for the simple reason that there are no unit tests. Without unit tests, bugs will be found later in the project life-cycle, possibly even after delivery. If customers have delivered software that is unusable, the fact of delivery becomes a negative pretty quickly..

On the positive side though, the tension between what's essential for the customer, and what developers need to learn to keep their careers alive is an interesting idea, and is something we've been looking recently at where I work. Is it a good idea to introduce a technology just because a programmer feels s/he should learn it? I'm not so sure.

If you need unit tests, write unit tests. If you don't, don't.

So in your case you would notice that for iteration 3 you need some unit tests. Then you can write them in iteration 3. You didn't need them in iteration 1, hence no need to write them in iteration 1.

The concept of technical debt will probably inserted into the discussion here. I think it is irrelevant. Yes, there is always technical debt. For example, I currently have a technical debt of several billion dollars because I haven't installed big data centers like Google or Apple have. So should my web app ever need to scale to a gigantic level, I'll have a problem. But not now. So it is a debt I can live with.

I have a similar feeling towards TDD. I use test driven developments for those parts of my code that needs it. I recently had to create a function that did some complex calculation. TDD was great for that, because I had a set of known inputs and a set of known outputs. It made sense to write the test before the code.

But I will not write trivial tests just to make the unit test coverage increase. I've seen tests written for simple getters/setters that just sets "this.birthday = date". If we do contact an alien civilization that have multiple birthdays, we will probably have to change the code anyway and the unit tests will have to be rewritten.

I may get some negative votes for saying this, but whenever I see a project with 100% unit coverage it's a red flag for me. This means they have wasted a lot of development time while writing trivial unit tests for trivial code.

Unit tests are great for parts of the code that needs them. But if your only reason for writing a unit test is to see the statistics "improve", you are wasting effort.

It boggles my mind that an article from barely over a year ago counts as "very ancient", that people clamor to add "(2006)" to article titles, etc.

If more programmers actually read stuff that was published longer than (gasp!) five years ago, perhaps there would be less naive noise about how New Methodology X is going to finally fix all these nagging issues in software development once and for all.