Ayende @ Rahien

Hi!
My name is Ayende Rahien
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

@

Posts: 5,949 | Comments: 44,546

filter by tags archive

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

Josh

Cheers to "Oren the Minimalist "

Damien Guard

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

Arne Claassen

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.

Graeme

I wish it were that easy to throw out fagile designs at work.

Dave Mertens

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.

Jason Y

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

Comments have been closed on this topic.

FUTURE POSTS

  1. The RavenDB Comic Strip: Part III – High availability & sleeping soundly - 11 hours from now

There are posts all the way to May 28, 2015

RECENT SERIES

  1. The RavenDB Comic Strip (3):
    20 May 2015 - Part II – a team in trouble!
  2. Special Offer (2):
    27 May 2015 - 29% discount for all our products
  3. RavenDB Sharding (3):
    22 May 2015 - Adding a new shard to an existing cluster, splitting the shard
  4. Challenge (45):
    28 Apr 2015 - What is the meaning of this change?
  5. Interview question (2):
    30 Mar 2015 - fix the index
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats