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: 5,972 | Comments: 44,518

filter by tags archive

It might work, but is it good enough?


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. Reducing parsing costs in RavenDB - 14 hours from now

There are posts all the way to Aug 04, 2015

RECENT SERIES

  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats