+972 52-548-6969
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
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.
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.
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