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,026 | Comments: 44,842

filter by tags archive

It might work, but is it good enough?

time to read 2 min | 226 words

Note, I am explicitly not asking if this is optimal. I am asking if it is good enough.

There is a tendency to assume 'it works, and that let sleeping dragons be. This is usually correct, my own definition for legacy code is "code that makes money". As such, any modifications to it should be justified in terms of ROI.

The term that I often use for that is technical debt, by no means my own invention, by a very useful concept. This allow me to explain, in terms that makes sense to the client, what are the implications of letting working, but not good enough implementation to stay in place. Or why I need to take a week or two with a couple of developers to refactor parts of the application.

We like to think about refactoring as: changing the internal structure of the code without changing observable behavior. Business people tend to think about it differently. A time in which the development team is going to do stuff that doesn't give me any value. The inability to translate the difficulty to terms that the business understand is important. And framing such discussions in terms of the technical debt into which they will get us into is critical.

Setting expectations about the behavior of the team is just as important as setting expectations about the behavior of the application.



I had the same problem convincing business people that we needed to refactor.

Turns out that showing them an output from running Ndepends on our code and in particular the word "Instability" shoved them in the right direction.

Jan Limpens

That's funny, especially because NDepends concept of instability is quite something else than how business people understand it.

Next time I work for meat industry, I am sure going to implement something "bleeding edge" there :), they are bound to like it.

Neil Mosafi

The way we handle this on our agile project is to avoid refactoring certain areas until a change request comes in around that area.

We then increase the estimate to give us time to perform the refactoring. This can increase a simple 1 day change to 5 days, but we explain the reason it will take so long is because we need to refactor certain areas of the system first in order to accomodate this change.

Of course we are lucky that the system was originally developed by someone else as we can blame them for the "bad design" we have inherited ;-)


"my own definition for legacy code is "code that makes money". As such, any modifications to it should be justified in terms of ROI."

Well said.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats