+972 52-548-6969
Two strikes, and you are out
I don’t have a lot of patience for repeated bugs. I just got a bug report that turn out to be in the result of the same feature as a previous bug I fixed.
I could have fixed the bug. But I didn’t bother. A repeated bug in the same area for the same reason usually indicate a fragile design. In this particular case, the feature wasn’t important, so I just ripped it all out, root & branch.
If it was important, I would have still ripped the whole thing apart, and then I would rebuild it from scratch, using a different design.
Fragile designs are one of the worst enemies that you can have, they will keep dropping things in your lap until you finally fix them once and for all. And I find that usually just starting from scratch on a feature implementation is the best way of doing that.
Comments
Cheers to "Oren the Minimalist "
This sounds a little extreme - there is always the risk that a new implementation will have a set of new bugs to deal with.
Personally I like to make the judgement call based on attempting to fix the bugs - are these bugs mistakes that should have been caught by tests, can we prevent this kind of bug with some refactoring or is it an indication that an area is indeed fragile and poorly structured.
[)amien
Fragile designs are usually what people who are having a hard time with unit testing point to and say "see, this testing thing is crap, i spend more time maintaining the test than the code", when really this is an indication that the design, not testing that's broken.
I've had my share of "quick this works for now" designs that paid me back with little bug after little bug and tedious testing, until I admitted the errors of my ways and fixed the design.
I wish it were that easy to throw out fagile designs at work.
I often wish I had the luxery the throw away the current code and start from scratch. Why. Because my manager ask me how long it takes to fix just this bug. 80% of the bugs (luckily we don't have that many bugs) are fixed within 2 hours including writing tests. Than he asks me how long it takes to rewrite the damn code.
Most fragile code didn't started as fragile, they became fragile when new features are implemented and existing code is altered. The all the (unit) tests still passes, doesn't mean the code is stable. It only means that it works like expected.
Via giving honest estimates of how long it will take to implement requested features and bugfixes for an app with a rewrite vs. without, I have (previously) successfully been cleared to rewrite the middle tier of an app.
When giving the cost of "just fixing the bug", report the whole cost. Report the whole benefit of rewriting or heavily refactoring part of an application. Then devs, project managers, and stakeholders will make an objective decision together.
And make your estimates with humility:
www.joelonsoftware.com/articles/fog0000000069.html
Comment preview