Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,492

filter by tags archive

Two strikes, and you are out

time to read 1 min | 155 words

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.



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.


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.


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:


Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 2 hours from now
  2. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 3 days from now
  3. The design of RavenDB 4.0: Voron has a one track mind - 4 days from now
  4. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 5 days from now
  5. The design of RavenDB 4.0: Separation of indexes and documents - 6 days from now

And 11 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    05 May 2016 - Physically segregating collections
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats