Ayende @ Rahien

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

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 18 | Comments: 72

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.


Comments

Dirk

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 ;-)

jdn
jdn

"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.

FUTURE POSTS

  1. RavenDB 3.0 New Stable Release - 13 hours from now
  2. Production postmortem: The industry at large - about one day from now
  3. The insidious cost of allocations - 3 days from now
  4. Buffer allocation strategies: A possible solution - 6 days from now
  5. Buffer allocation strategies: Explaining the solution - 7 days from now

And 3 more posts are pending...

There are posts all the way to Sep 11, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    01 Sep 2015 - The case of the lying configuration file
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats