[PaddyCorry]

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.

[Tichy]

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.

[j_baker]

The problem with that train of thought is that the point when you realize you need tests (you're shipping software with stupid bugs that could be prevented with a few tests) is often after the point at which it's easiest to write them. I'm not going to be the TDD zealot and say you need 100% coverage and you need to have your tests written up front. However, I will say that sooner is usually much better than later when writing tests.

[hello_moto]

Guess what most developers do?

Let's admit it, most devs don't test. There. I said it. Most devs just want to write more features, more new code, more design patterns, more cool algorithm.

Dev 1: "Testing? Testing is not my job. Go ask the QA to do it".

Dev 2: "Yeah... we're just not born to do testing, it's just not how our brain is wired".

Dev 3: ... more excuses why dev shouldn't test ...

I get it that devs aren't good at usability testing. But the majority devs I met don't even want to test their own code. Some don't want to write unit-test, some don't even want to test the functionality of the code they just wrote.

sigh

[heathlilley]

I think there is something incredibly powerful about a continuous integration system that is fully bootstrapped. Being able to know the instant something is broken and run a single build script after a SCM check out to have a fully functioning system should be the goal of every enterprise system, IMO.

Proper unit tests with broad coverage are foundational to both of these ideas.