On Aug 25, 2012, at 17:24, "Guillaume Rossolini" <[email protected]> wrote:
> What you say is true, versions get old. But as Lester pointed out, they
> work. that is why some computer systems that have been outdated for years
> are still functioning today. It is hard to make a case for rewriting code
> that already works, don't you think?
Actually, no. In fact, if anything, I think it's just the opposite: it's hard to make a
case for letting code stagnate. No matter how stable an app may seem, there will come a day when it
will suffer a serious blow. It might be that a critical component has a major security breach, or a
business requirement comes along that forces you to play nice with another system in such a way that
it can only be done with newer software, or the underlying hardware breaks and cannot be replaced,
or the company grows and the app can no longer scale... whatever. The world changes, and it's
going to take your app with it one way or the other.
The term is technical debt, and like financial debt, you must deal with it, you must keep ahead of
it. If you're pouring all your resources into new code, then you're piling up technical
debt.
Yes, refactoring code to modernize it isn't always fun, but if you do it regularly, then the
debt remains low and you settle in making making many small changes at a constant pace and over
time, rather than making big changes too quickly. Other benefits come from regularly revisiting
code, too, e.g., fixing hidden bugs, increasing performance, reworking algorithms and flows with the
benefit of experience and hindsight, etc.
How much maintenance, as a share of overall work, is right for an app varies with the overall
quality of the code and how rapidly the app is evolving. It may be 20% or 80%, you have to decide
for yourself. But if all you're doing is adding code without ever refactoring code, you're
setting yourself up for a real mess when the sh** hits the fan, and you're doing your company
(or customers, or clients) a terrible disservice.
BTW, before you blow this off as an unrealistic view, consider my own situation. A few years ago, I
took over management of a few million lines of code that had largely come to be via the throw it
together and never touch it again method. Most of it was written in the PHP 4 era (some in the PHP 3
era), and it had things like reliances on pre-1.0 beta releases of pear libraries that had long
since lived a full life and died in unmaintained peace. These were mission critical applications, so
we couldn't just toss them out or stop new development. At the same time, they were starting to
become problematic, with serious performance issues and security flaws.
Our approach was simple: whenever we added anything, we took the time do it the right way, which
almost always included refactoring old code that was involved. And, we spent most of our time fixing
things, pulling dependencies on third-party libraries (like pear), and so forth. Over time, things
have improved dramatically, and now most of that old code at least runs under 5.3 comfortably. Our
newest apps specifically target 5.3 and will be switched to 5.4 as soon as Zend gets its act
together and releases Zend Server with 5.4. Perhaps most interesting, the business users are really
starting to understand the importance of staying on top of technical debt, since they were bit so
badly by not doing so and are now starting to reap the benefits of doing so.
My point is, I feel your pain. But you have to power through that, get the code cleaned up, and then
get it on a maintenance schedule that keeps it that way. The rest of the world is not going to slow
down for you, so stop waiting for that to happen and just jump in.
Regards,
Bob
Notice: This communication, including attachments, may contain information that is confidential. It
constitutes non-public information intended to be conveyed only to the designated recipient(s). If
the reader or recipient of this communication is not the intended recipient, an employee or agent of
the intended recipient who is responsible for delivering it to the intended recipient, or if you
believe that you have received this communication in error, please notify the sender immediately by
return e-mail and promptly delete this e-mail, including attachments without reading or saving them
in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail,
including attachments, is prohibited and may be unlawful. If you have received this email in error,
please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if
any).