2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 27, 2009 ( 3 comments )
- Refactor Legacy Code
Some businesses think that software is a write-once activity. It is true that once written software does not change but the world around us does and static software quickly becomes out of date.
Code rot is real. Even if a system was well written at one time we often cannot anticipate how a system will need to be changed in the future. And that is the good news! If software does not need to be changed then it probably isn’t being used. We like the software we build to be used and for software to continue to provide value it must be easy to change.
You can build a house out of cardboard and on a nice summer day it will hold up well but at the first rainstorm it will probably collapse. Builders have a whole set of standards and practices they follow religiously to make their buildings robust. We as software developers must do the same thing.
I have a client on the East Coast who is one of the leading financial companies on the planet. They are particularly challenged by their huge amount of legacy code. Most of it was built by contractors or their top developers who were pulled onto the next project as soon as the first version was completed. Junior developers now maintain those systems, some who do not understand the original design so they hack away at it to make changes. Eventually they ended up with, well, a mess.
At a meeting with several of their senior managers and developers I said, “So let me get this straight. You became a leader in financial management by going out and finding top fund managers to manage your funds, have them research and acquire the best investments and then you freeze the portfolio and pull the managers off onto other projects.”
They said I got the first part right but the fund managers stay with the funds and continually adjust their portfolio because the market is constantly changing.
“Oh” I said, “So you go out and hire top software developers, have them design and build a system and then you pull them off when they are finished to work on a different project.”
“So are you saying that our software is a critical asset and like any asset it needs to be maintained?” one of the mangers asked.
Bingo.
{2 Comments }
{1 Trackbacks }
Previous Post: « On Techniques for Agile Trainers
Next Post: Writing Changeable Code »
Hi, cool post. I have been wondering about this topic,so thanks for writing.
You are very welcome, Andrew!