It’s a process, though. Doesn’t lend itself to a blog post :-). My approach generally is to put no logic into the UI at all. That way I can simulate the outermost (view, if you will) layer and use TDD to build all the code that does anything. Then I build the front end and use a back-end simulator to test it. That last step is mostly manual testing, but there isn’t much to test.

I disagree with that statement entirely. The longer you let a bug fester by not fixing it, the harder it is to fix, but when you fix them as soon as you find them (ideally during initial construction), they are trivial to fix. Use TDD. Write your “tests” (really examples of how you expect to use the code) first. Augment TDD tests with unit tests as you work. If anything goes red, immediately bring it back to green. Do not release code with known bugs in it.

Put simply, you don’t know what you’re talking about, and clearly, you haven’t paid attention to irrigation systems recently. They do everything from predicting the amount of water you need from aggregated weather reports and sensors to accurately metering water to single plants, and if you’re talking about, say, a multi-acre University campus, the complexity is nontrivial. And they have a sales website of course, but the main use of the website is to remotely program and adjust the system. It’s part of the control system. They base their “no known bugs” on customer bug reports, internal testing, and of corse, security is part of that. $1M of industrial landscaping dying because your system fails is hardly “no actual weight.” The fact that they do that with 7 or so teams is pretty impressive.

If you have “tens of thousands of software engineers” on a single product or project, bugs are the least of your troubles. You need to learn how to scale the work down and how to work effectively. This many people is Parkinson’s Law in action. Lots of people spinning their wheels.

I’ll add that my stickie notes are a to-list, items retired after, at most, a day or two. It’s a way to avoid context swaps. I’m not tracking anything.

Sarcasm aside, post it notes are a to-do list, not a bug-tracking system. The notes live for a day or two. To-do lists can be a useful tool. For example, when I do TDD, things occur to me that are important but I don’t want to do this instant. They go on a todo list and are dealt with the instant I’m done with the current thing. The point is to avoid context swaps, not to track anything.

So your big tracking system is postit notes on a white board instead of an electronic system.

Revolutionary!