Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have just been put in charge of a code project with maintainability problems. What things can I do to get the project on a stable footing?

I find myself in a place where we are working with a very large multi-tiered .NET system that is missing a lot of the important things such as unit tests, IOC, MEF, too many static classes, pure datasets etc. I'm only 24 but I've been here for almost three years (this app has been in development for 5) and mostly due to time constraints we've been just adding in more crap to fit the other crap. After doing a number of projects in my free time I have begun to understand just how important all those concepts are. Also due to employee shifting I find myself to now be the team lead on this project and I really want to come up with some smart ways to improve this app. Ways where the value can be explained to management. I have ideas of what I would like to do but they all seem so overwhelming without much upfront gain. Any stories of how people have or would have dealt with this would be a very interesting read. Thanks.

share|improve this question

migrated from stackoverflow.com Feb 17 '11 at 21:04

This question came from our site for professional and enthusiast programmers.

    
I would suggest investing heavily in code coverage tools like Re# and StyleCop (free), etc. It is much cheaper to have software detect problems in source code, at least for the first pass. –  Job Feb 17 '11 at 23:02

9 Answers 9

up vote 13 down vote accepted

Budget time to attack technical debt. You just gotta do it. Which parts you attack first depends on where your developers are spending the most time currently, but it's more important that you get started then that you get started on the ideal things. If you are using Scrum, put specific pieces of technical debt work on your backlog and treat them like features until you get a handle on them.

Working Effectively With Legacy Code is highly recommended, and would probably be useful. I haven't read it, but it seems to have a lot of information on getting unit tests into legacy code so you can modify it and bring it up to date safely.

Use the credit card analogy with management - you are "paying interest" on everything you do because it's so hard to accomplish anything. If you pay down your technical debt, you will free up those resources and be able to develop new functionality more rapidly in the future. If you don't, your "interest payments" (paid in development time) will continue to accumulate and your team will produce new functionality slower.

Maybe start estimating the amount of time you spend each cycle struggling against technical debt to give them an idea of how much has already accumulated. Describe what a fix or feature change would look like in a maintainable system, what it looks like in the actual system, and what changes would need to be made or could be good first steps to get there.

share|improve this answer
1  
I have read WEWLC, and it's really good. Probably the most valuable thing the book provides is the knowledge that there ARE ways of dealing with the crappy things you come across in legacy projects and you CAN reverse the process of software rot. –  Jason Swett May 7 '13 at 16:27

Roll technical debt into bug fixes and additional feature.

I've found an iterative approach to improvement yields the best results. The mantra at my work is improve the quality of the code whenever you touch it. Each piece of work whether it's a bug fix or feature starts with an analysis of what can be fixed/refactored/cleaned up. We try make the refactor on par (in scale) to the work that we have to complete.

Create an ordered list of the problems in the code base. Make sure everyone is aware of the list and the priority order. Whenever they get a piece of work they should look for a problem from the list that tied to the code you will be working on.

This will not fix everything. There are some refactors or fixes that require a large chunk of time and resources. I generally try to tie those to other large pieces of work that will benefit.

share|improve this answer

It ultimately depends on how good your people are on the project. If it is the same crew that created the mess, then you have little chance of making it better with the same group. Analyze your staff, find out your weakest members and replace them (if you have the ability to do so).

"You can't make a silk purse out of a sow's ear".

share|improve this answer

I'm currently reading Brownfield Application Development in .NET which, basically, is about how to deal with the problems you currently have. So far I like most of what it says (not quite everything - but this is the sort of book to help you think your own way through the problems, not one that is intended to be completely prescriptive). It may help in a couple of ways - it shows you're not alone; it hopefully will give you hints as to how to address some of the issues.

Fundamentally I agree with most of the approaches - you can't fix the whole thing overnight, but you can improve it incrementally in very small steps. And yes - Technical Debt is the metaphor you need to use.

share|improve this answer

One option is to dust off your résumé and start job hunting.

A good question to ask yourself is whether this badly run project is indicative of how the whole company is run. If the answer is yes, then ask if you're getting paid enough to stay in a badly run company.

share|improve this answer
    
Yes, some questions to ask: Did management hand you an abandoned ship? What happened to those other people that used to work on the code base? Did they move on after throwing the towel in the ring? Perhaps the project is already to be phased out without it being communicated to you as such? Is there more to fix then there is to salvage? –  Joppe Feb 21 '11 at 17:23

Many times you can push refactoring by upper management if you can tell them it will be a performance upgrade or fixes some existing bug. Don't re-factor just to change something to what you would do, especially if it works. Bug fix time can also be a good way to fit in some refactoring as you are already there anyway. Be assertive and don't look at it as your are younger than your fellow coders. Start with something small like getting in some unit testing and work from there, you might expose some bugs that can get management to give you cycles for other things.

share|improve this answer

In cases like that, I like to try to streamline the project as much as possible. Find out which features are absolutely necessary to get it to move forward. Any system that has been around for a long time probably has a very long backlog. A lot of these items will be critical and a lot will just be "bells and whistles".

As far as testing, unit tests will definitely be helpful, but you may want to ask some of the non-tech staff to participate in testing and submit bugs to your team members.

Good luck.

share|improve this answer

You could try to explain the technical debt this project has for one idea of where to start. You could also try to bargain that due to employee shifting there has to be some time spent getting up to speed on the code and this means putting in some tests to help ensure better future development as the tests can help prevent bugs and make things easier for new people to work on the project possibly.

share|improve this answer

I might just be stating the obvious, but hey.

Write a small unit test that exercises a chunk of code that has problems, then refactor said chunk, making sure that the test still passes. Move on to another chunk of code, the one you can reach most easily from that tiny portion of solid ground you have just built. Lather, rinse, repeat.

This will also help you with getting a bit more familiar with the codebase.

After you've been doing that for a while, you'll figure it's time to do some more extended refactoring. Figuring out duplicated code, violations of the DRY principle... you know, the usual stuff. By then you will have an arguably decent code coverage, which will allow you to shuffle methods around, extract interfaces and all those amenities.

Always leave the codebase a bit better than it was before you started hacking your way into it. I'm pretty sure it's a small investment that will pay off, even in the not-so-long term.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.