I work in an office where I’m the only developer on a very large projects, so sometimes I push myself to get some results quickly and I ignore any exception handling and tell myself it’s ok because I’ll do it later. I’m involved in a project right now, an enormous project, with no system to really track exceptions and I’m having to go back and re-tool my code. I think I’m going to give ELMAH a chance.
Thanks for this post and from now on, that will be my first step when developing a new project.
As usual I like your post. I did find one section that slightly tweaked me Although I remain a fan of test driven development…practice rather than theory
I think you misunderstand TDD. TDD != unit test everything, it is a development process that is test driven. I am not saying that you are wrong in not practicing TDD, but I would think you would want to read up on it before making proclamations on it. The best I could find this morning was http://www.developerfusion.com/article/9375/tdd-in-practice-dealing-with-hardtotest-areas/2/. I know there are better.
Although Apple does collect crash reports, they don’t allow devs to see them. However, the log’s location is documented and tons of different logging solutions exist to retrieve them automatically and send 'em back even here on the Mac front – from Smart Crash Reports to PLCrashReporter to homegrown solutions
I started trapping errors on a whole host of websites at my last company years ago and it was an enlightening experience. Started with old ASP sites on shared servers and the then-new .NET sites. We found bugs and security issues that no user or client was reporting to us. Like Microsoft’s research, the vast majority of the issues were from a very small set of bugs (all written by ex-employees, of course). Two interesting side effects:
I took a lot of satisfaction the day the RSS feeds of our errors went from dozens or hundreds in a day to one a week or so.
Patching the same issue across dozens of old web sites with similar code helped to focus us on being better about code sharing and deployment.
While there are many other valid reasons to practice TDD, as a pure bug fixing mechanism it’s always seemed far too much like premature optimization for my tastes. I’d much rather spend my time fixing bugs that are problems in practice rather than theory.
I’m sure you still don’t get TDD: Its not a bug fixing mechanism (apart from bequeathing a test suite you can use to check for reported bugs), its a design fixing mechanism.
I’d rather spend my time writing the next app than running round fixing bugs I’d rather not have put in in the first place.
btw How do you know you’ve fixed that top bug? Do you have tests for that? What about when you’ve ‘fixed’ 19% and you’re looking at the next 1%, how do you know that the 19% are still fixed? And just how many bugs do you have?
Bananas are green when you buy them at the store [at least often they are], they will get yellow once you take them home and wait a while
So the store is selling you an unfinished product, it is finished at the customers home. Sure, this works very well, but it is something frowned upon by most developers, customers, and companies. I’m not buying a car that is not really working just so I can report back to the car vendors what problems I have and they can fix them and one year later I really have the car I thought I bought one year ago.
…to continue my thoughts. For those usability bugs without crashes, I like what Microsoft did with the Windows 7 Beta.
There was a easy to find link Send feedback where you fill-out a very simple form and you submit it. A bit more work to process these feedbacks, but at least you have a good chance someone that has a problem will use that if it is easy to find. Most of the time, users don’t go out of their ways to find out how/who/where to submit problems/issues.
Interestingly, we just yesterday released our final beta version of a product that is similar ELMAH but more comprehensive and compatible with any .NET app (WinForm, WPF, Service, not just web apps).
TDD? duh I read about TDD before and sure it makes your application rock solid because you build it from testing. But considering the time constraint, I’d rather skip writing test scripts until I got enough time do it. we don’t ship the test scripts to the customer anyway. I mean, the customer doesn’t care whether or not we wrote test scripts; they are only after of the final product. There’s something really annoyed me in TDD. I read one article that suggests writing first the tests before the application code to the point of trying to call a method you never implemented yet. I think that’s stupid. The test will of course fail because the method doesn’t exist yet. Also, most of the times, writing tests is more difficult than writing the application itself. What works best for me is a thorough review of the code before testing.
… my thoughts again on non-crashing bugs. Stackoverflow is a good example of a relatively simple way to submit problems/issues/comments. But still too complex for a lot of users. Personally it was a big turn-off to have to create an account with yet an other system to submit bugs/problems and I did not do it.
I actually take this to another level: every exception generated by any test or production server is emailed to every engineer on the development team immediately, with the stack trace and as much detail about the context of the exception as the error handling code can provide.
I can’t wait until someone happens to look at a log file or the Event Viewer to know that something is broken. And constantly being annoyed by emails is a great incentive to fix bugs quickly.
I’m sure you still don’t get TDD: Its not a bug fixing mechanism (apart from bequeathing a test suite you can use to check for reported bugs), its a design fixing mechanism.
I don’t know why I should be the one to defend Jeff on this point, but he does say there are many other valid reasons to use TDD, just not as a bug fixing mechanism, so it seems he is agreeing with you.
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???
If you fix a bug in new code, then by definition, a user won’t encounter it. Would you rather leave it in until it becomes a practical bug???
And if the bug is in code that no user will actually cause to be executed, then why exactly do you need that code?
Do you handle client-side (Javascript/CSS) errors as well? You could use some quick ajax calls to send the Javascript error log to the server along with browser and browser version.
I agree with this article completely. However, this is really only practical for certain types of systems. I wouldn’t want to just get the space shuttle launch control software out there and wait for the exception logs. Ditto for any medical software.
