Jeff,
Do you realize that with posts like this, irrelevant of your understanding of TDD, you are promoting many of the problems things like automated unit and regression tests have solved? When you ship software where one small bug can make a business lose thousands of dollars, how can you justify this?
Software is not only about stack overflow web site no matter how many millions of users it has.
@Jeff Atwood
If you fix a bug that no actual user will ever encounter, what have you actually fixed?.. I’d much rather spend my time fixing bugs that are problems in practice rather than theory.
Young man, what the hell are you thinking??? Jim Cooper
I agree with Jim Cooper here.
If I was being interviewed by Jeff Atwood for a job with him and he said that I would tell him he was an incompetent software engineer and walk out. Such an utterly stupid remark.
A bug is a bug is a bug; it is not a theoretical or a conjectural concept.
It is akin to saying that if an electrician wires a socket incorrectly (for whatever reason) in your house then the ‘bug’ is only theoretical if no person uses it.
What an unprofessional mindset.
^ sorry, but the truth is there will always be bugs and they need to be prioritized. You can fuss over the usage of the terms practical vs theoretical, but he makes a valid point, one that’s obvious when you quit harping over his verbiage.
A bug that results in an exception is a bug that crops up in a valid use case and needs to be fixed. These fixes necessarily take priority over TDD. If you want to put in the unit tests to catch the bug afterwards, great, and that’s part of his point too.
All this stuff just makes me think we need to simply retire the word ‘software’. Pretty much all sentences which contain the any of the phrases ‘software project’, ‘software expert’, ‘software technique’, ‘software bug’ are wrong at least as often as right.
No-one uses ‘hardware’ in the same way, no-one thinks a bridge is really the same as a disposable shopping bag. Those responsible for making those two things would never lecture each other ‘when building hardware, you need to …’.
But too many people still have this strange idea that there is some meaningful commonality between a game, a website, a service, an embedded device, a product, an in-house application, …
Jeff,
I have to admit you’re a far better writer than me. We’ve updated the copy on the home page of our online exception reporting tool to use the term “exception-driven development”, which we all liked a lot.
In case someone is interested, we are making a web app called CrashKit which collects exceptions from your web/desktop applications. We already support Java, Python, PHP and JavaScript, but we’re in an early private beta stage, and there are many areas we want to improve. Still, if someone is ready to become an early adopter or is just plain interested, please visit http://crashkitapp.appspot.com/.
Come on Jeff - put an end to all the speculation about your competence and post the source to StackOverflow. Think of all the help you’d receive…
The source to FogBugz has been published for years without Joel being rumbled, so you could just get away with it.
Jeff, would you please fix the Read older entries link on the main page? It always takes you to a specific older entry, rather than the previous page of entries.
I have to admit jeff, while you’re mostly right about the average end user only being able to give semi coherent ramblings that are usually useless, there are people out there, who arent computer programmers per se, who could definitely help out quite a bit in fixing bugs by describing what was happening as, or before the bug happens. most error reporting software simply takes basically a screen shot of what is going on at the moment of the crash, but those few moments of usage leading up to the crash could be as important, if not more so, than what was happening at the time of the crash.
Also, I’m very sorry about the abundance of commas and excessive modifiers in that last comment. 4 am is a very bad time for proofreading.
Written like a truly old-school MS programmer. Make a buggy product and let the users test it for you.
But then this blog is all troll lately.
I also have a hard time following the logic of the post. Oh I guess that’s because it’s not a logical argument. The only thing it says, which is totally f’ing obvious, is that ‘bugs happen, monitor real errors, quickly fix and turnaround if you can’ Unless you’re a hobbyist programmer, you or your team are already doing this.
When a user informs me about a bona fide error they’ve experienced with my software …
This should read ‘when a user experiences a bona fide error’. But then again you’re also making a judgment call on what a bona fide error is. Just because your application hasn’t melted down into a smoldering heap of bytes doesn’t mean a bona fide error hasn’t occurred. I’ve read a lot of your comments and seen the way you approach issues in UserVoice.
We don’t ship software that has many exceptions in runtime. Exceptions are meant for developers and testers to bring the system to a halt as quickly as possible so that as many real bugs can get fixed before we ship.
You might make a few good points, but you obscure them with your smack-down rhetoric. The worst part is many junior programmers read this blog and think they’re better off for it.
While I always expect users to point out the problems with my applications, sometimes I just don’t expect the (higher than expected) number they come up with. Users are certainly great at improving your work I find but yeah, its always good to keep a crash log as well. - Prague Hotel.
Need to set filter.
This blog has descended into navel gazing of the most egregious kind.
Get a life, post less, and make them interesting for fecks sake
I’m sick of that stupid iceberg picture. (1) It defies basic physics; it would roll onto it’s side. (2) Icebergs don’t look like that. (3) You can’t see that far under water anyway. (4) Don’t tell me to lighten up.
@CalmDown:
Your responsibility as an engineer is to provide the best experience possible for the customer. There are always deadlines to meet, but if you find yourself continually unable to meet them, you either need to work on time management, or work on expectation management with your boss and/or customer. Do not let your boss or customer drag your product down into mediocrity. Left unchecked, they sometimes will…though unknowingly.
Worse still is this unspoken agreement among some engineers that complexity is a necessary ingredient to every codebase. I run into it occasionally and it is very disheartening. It seems like since they’ve always had experience dealing with (and writing?) messy, complicated code, a codebase that is actually designed is a bit disturbing. Kind of like how people tend to go from one dysfunctional relationship to the next until they figure out the common factor. I know some of this sounds ridiculous, but I’ve seen it more than a few times. They never seem to make the connection that simplicity often begets a lower bug count. I suspect they feel a bit insecure at the prospect of someone doing a better job than they. That, and some people tend to slide into being self-impressed with what they’ve done instead of pushing it to be even better.
I don’t mean this to be navel-gazing, but it underscores a larger problem of people who just do the work without reflecting upon it working alongside people who do.
I would prefer to call it error-driven programming. I sometimes avoid exceptions because I think they are a bad model for handling errors in C++ (I am of the opposite opinion when it comes to, e.g. C#), but the applications I produce still provide error logs, which can provide the same information.
I wholeheartedly agree with the principle though… in my experience the most bugs are found once the software is in the hand of the users. They do things that I just never seem to think about trying and the result is that they turn up problems in my code that I never would have even considered looking for.
This doesn’t mean you should ship buggy software of course… this is exactly what alpha and beta tests are for. 
I’m not sure I agree with you on this Scott…
This may work for a site like stack overflow, but if you have a complicated stateful server application the cost of debugging and fixing a bug when it happens in production is many orders of magnitude greater than fixing it when you write a unit test.
For these reasons, and more, I believe that problems in a large stateful production application are many orders of magnitude more expensive, therefore finding as many of them as you can at development-time is time well spent.
That said, for a site like Stack Overflow this methodology may work better. Though I’m sure you still have some overheads of potential data corruption, down-time, and patch release.
You also forget that a large part of Test-Driven Development is about design, in addition to testing, though this may be more relevant to a framework or public API than to Stack Overflow.
Where by Scott I meant Jeff… that’s how we pronounce it in the UK dontchaknow?
The truth is that Jeff is a uncapacited person, so he needs to justify his lack of ability.
That’s all good, but it bothers me to no end when a company implements automatic crash reporting and then updates their website to make it impossible to report bugs without going through 10 layers of non-technical support personnel.
@Sam (who said)
It is akin to saying that if an electrician wires a socket incorrectly (for whatever reason) in your house then the ‘bug’ is only theoretical if no person uses it.
What an unprofessional mindset.
…no, It is akin to saying that if an electrician wires a socket (period) in your house, then a person sticking a plastic knife (with an emf-sensitive trigger attached to an explosive charge) into the socket would be something he would not be reasonably expected to account for when wiring the socket (the theoretically implausible…not impossible…test case).
A lot of people seem to be taking the view that all tests are created equal, but that’s obviously untrue. Stating this in an article, as was done here, hardly seems like cause for an uproar.
If you’d prefer an electrician to preemptively account for you sticking a plastic knife into a socket (maybe a cover that deploys when it detectes plastic at too-close a distance?), then fine…you’re being thorough, go for it…I’m not buying a $4,000-spork-defeating socket for my house, though.