A week ago I was in the unenviable situation of having to dig through a large number of legacy apps and libraries in Java, C and VB to find references to a database attribute that was going to be retired. Examining just one file took a long time, since a file containing a dangerous reference might have been imported as a helper lib in other projects - and to make things worse, I couldn't immediately see if these projects were obsolete or not.
In my current project, my fellow employees have a very good overview of which systems are used where, and which versions are deployed, so when I am unsure I can always ask them. However, had they quit and taken that knowledge with them, I would have faced a combinatorial explosion of repository source versions, deployed versions, and production environments that would have made my task impossible; not just very hard and time-consuming as it was now.
For clarity and maintainability, if a system is obsolete you should always at the very minimum comment database tables, tag repositories and check in README files to the repositories that clearly show that these things are no longer used. Even better would be to move the data to separate "graveyard" branches/databases. I think the best of all would be to delete the obsolete files, since you can always reconstruct them from the repositories and backups in the extremely unlikely case that you would need them again. I understand if some people are reluctant to do that, the human urge to hang on to things "just in case" is strong.
It is a project management anti-pattern to keep obsolete projects and modules in your source repositories, and obsolete database tables on your servers. You will soon accumulate a technical debt which, like the debts in your bank accounts, will keep growing over time. Keeping track of possible dependencies between systems and components becomes progressively harder, and it will becomes increasingly difficult for new developers to get an overview of the architecture. More and more valuable development time will be spent on "the debt" instead of useful tasks. Developers will not have the courage to refactor, and this will feed the negative habits of adding stuff but never removing - not very agile.
Luckily the managers at my current company have been convinced to set aside developer time during the summer to clean up the source repository and move obsolete code to a separate view. At this particular company, I won't have the tedious task of searching through obsolete code again. For all our sakes, I urge you to do the same. :)
Subscribe to:
Post Comments (Atom)
4 comments:
Interestingly, I don't agree. It's not an anti pattern in itself. In fact, it's just a symptom of another anti pattern.
In a project, you should be able to delete code from the repository until your tests break. The code you deleted can safely be deleted from SVN. It's no real danger, since you always have the history. And since there are no tests that prove that this code is needed, no one actually should depend on it, right?
So the anti pattern is the absence of tests, on several levels. Obsolete code in the source repository is a symptom of fear to change. You can only change things with confidence if you have tests to back it up, which means that the code haven't been deleted because there is no confidence that nothing will break from such a change.
@ola That is of course the ideal solution, but how often do legacy systems have this amount of test coverage? :)
It' Ok..But I want to know how to setup the Hudson build automation with base cleasecase.
Please help me?
It is a project management anti-pattern to keep obsolete projects and modules in your source repositories, and obsolete database tables on your servers. You will soon accumulate a technical debt which, like the debts in your bank accounts, sewing factory , sewing of ladies suits , sewing expert , sewing factory near me , lawn suits , pakistani lawn suits , pakistani lawn , buy pakistani lawn suits online , pakistani lawn suits online , pakistani lawn suits online sale will keep growing over time. Keeping track of possible dependencies between systems and components becomes progressively harder, and it will becomes increasingly difficult for new developers to get an overview of the architecture. More and more valuable development time will be spent on "the debt" instead of useful tasks. Developers will not have the courage to refactor, and this will feed the negative habits of adding stuff but never removing - not very agile.
Post a Comment