What to do when you inherit an unmaintainable codebase? [duplicate]

Question

Possible Duplicate:
Techniques to re-factor garbage and maintain sanity?
I've inherited 200K lines of spaghetti code — what now?

I'm currently working at a company with 2 other PHP developers aside from me, and 1 junior developer.

The senior developer who originally built the system we're all working on has resigned and will only be here for a matter of weeks. The other developer, who is the only other guy who knows anything about the system, is unhappy here and is looking for a new job. I'm very real danger of being left behind as the only experienced developer on this codebase.

Since I've joined this company I've tried to push for better coding standards, project documentation, etc and I do think I've made some headway, but the vast majority of the code is simply unmaintainable and uncommented. A lot of this has to do with the need to get things done fast at points in the project before I joined, but now the technical debt is enormous, even with the two developers who do understand the system on board. Without them, it will simply be impossible to do anything with it. The senior developer is working on trying to at least comment all his code before he leaves but I think the codebase is simply too vast to properly document in the remaining time. Besides, when he does comment it still doesn't make things as clear as it could.

If the system was better organized and documented I could probably start refactoring it incrementally, but the whole thing is so tightly coupled that it's very difficult to make any changes in one module without having unintended knock-on effects in other modules. Naturally, there's no unit tests either, and I honestly don't think this codebase could possibly be unit tested anyway given how it's implemented.

There also never seems to be enough time to get things done even with 3 developers and 1 junior developer. With one developer and one junior, neither of which had significant input into the early design of the system, I don't see how we could possibly get anything done with keeping the current system working, implementing new features as needed and developing a replacement for the current codebase that is better organized.

Is there an approach I can take to cope with this situation, or should I be getting my own CV in order as well at this point? If it was just me and the junior designer who would be left I'd go for the latter option almost without question. However, there's a team of front-end developers and content managers as well, and I'm worried what would become of them if I left and put them in a position where there would be no developers at all. The department might just be closed down altogether under such circumstances, and then I'd have their unemployment on my conscience as well!

Answer 1

The similarity your situation has with what I've experienced about 3 years ago is frightening:

• same setup: undocumented, cowboy coding
• the "senior" guy that made the thing is gone
• the remaining guys know something about the existing code base but not a lot.
• thought the thing was presented as "working" and my job was introduced as "just add some extra features, no major recoding", it was clear that nothing was doable without a major re-hauling.

I don't know what the best approach to this is, but I can tell you how I've dealt with the thing:

• first off, the cowboy coding environment and lack of documentation (and testing, in my case) was considered a good thing by everybody, so proposing to change that in the sense where some time was spent doing docs, implementing a test infrastructure etc was denied right from the start. What I ended up doing is implementing all this "on the down low". Without actually declaring it as a task, I've tried spending 1-2 hours a day (for like, the first 2-3 weeks) just organizing the code, putting it on svn, making some docs, and some basic unit and integration testing. Functional tests, CI and higher order organizational stuff was out of the question in such a setup, so that was left aside, but at least some advancement was done.

• second, and again, without really declaring it as such, I've accepted my "just add a new feature, nothing more" tasks as is, but instead re-hauled the whole module that was impacted by that task (in order to make the task implementable). I've simply demanded some extra time, but without actually declaring it, remade the existing, production code first, and then added the extra features. The up side here was that the original code, even though it was in production for a while, was so bad and un-performant, that a simple, common sense refactoring made it substantially faster and that gained me the approval for the extra time I demanded.

• finally, about 2-3 months of this, I started looking for a different job, because it was clear that this was not something I wanted to do on the long run. Long story short, I've quit this job after about 5 months, in which time I managed to implement a decent portion of the functionality that was demanded of me, but not all.

Now, here's what I've learned from it all: sure, if possible avoid such jobs, it's better to work in a clean, structured environment, where the software development process is recognize for what it is and treated with respect. On the other hand, I cannot deny that my short period of working in such conditions taught me A LOT about how to deal with issues in such an under-pressure environment. It also made me appreciate even more all the protocols and methodology needed for good software development.

So in short, if you can afford a few months of this, do it, it will be an interesting experience (just as long as you have a clear way out in the near future). If not, just leave it as soon as possible and be done with it.

Answer 2

There is no easy answer to the question.

From what you have written, the biggest problem appears to be one of project management. Too many tasks were performed too quickly. You can implement the world's best coding standards, automated tests and so on but if this practice continues, it will all be for naught. You need to change the thinking from a features and deadlines first and quality a distant third to a quality first, pick either features or deadlines for second or third mentality.

You need to talk with your management to improve this. It may not all be your immediate management's fault. Maybe business conditions are changing or customers are being difficult, but it is something you need to address. If you cannot address this, walk away. Companies need good developers more than developers need bad companies.

Assuming you can get some commitment for that, start with a small piece of the product, such as one you need to modify or extend and make it better. Whenever you have a coding task, pad the estimate a bit and spend a bit of time fixing or improving something.

At the same time, start enforcing better practice such as code reviews, use automated unit tests and so on. This is mandatory for all developers, especially the senior ones.

Michael Feathers has a great book, Working Effectively with Legacy Code, on refactoring code to make it more testable. I am unfamiliar with PHP tools but there is surely an equivalent of the .NET StyleCop to enforce coding standards. Also identify whether components of the system can be replaced by third-party libraries. This offloads the maintenance burden from you and likely increases the code quality.

Also consider gathering some metrics. It may be worthwhile tracking how much of the code base has been cleaned up, perhaps a percentage of the code or number of components. One way to demonstrate the benefit of the work to management is compare defect detection rate and number in old code with the cleaned up code. Another is to look at the time taken to complete modifications to the old and new code.

Once this has been successful for a few components, work with the other developers on the overall system design. How should the system actually work? This may be difficult, particularly if the product is changing rapidly, but a high level design for the system is something to aspire to with the incremental changes. Without it, the quality of individual components may improve but the system will be a mess.

You should then be in a situation to reassess where you are.

One last point I want to address is your indebtedness to other developers. From what you have written, the state of the product is not your fault. Software developers tend to feel a strong bond to one another and is one of the reasons many of us love the industry. Fixing a broken product will look good on the CV. Drowning in negativity and futility will drive you crazy and burn you out. You have to know where to draw the line and trust others to look after themselves.

Answer 3

There are several approaches to this, but fundamentally a lot will depend on management support - and if you haven't got management that understands what differences a testable, solid, documented codebase means, then maybe polishing your CV would be the best route.

Do you have parallel environments? The first thing I would suggest would be putting in place a regression testing framework - taking a regular snapshot of the production data and using that in for a parallel dev/UA environment. Then start testing refactored, new or edited code there before release into production.

If you can't unit/integration/system test from scratch, then you should at least start to test properly any new/changed code - and you'll need the parallel environment for that. Then at least you'll start to build up some confidence in the changes that you are making.

Once you've got some testing in place, then maybe try to get some coverage tools so you can start to guess at the extent of your problems.

Investigate automated documentation too - I'm currently in a .net world and being able to enable automated documentation and then have missing documentation marked as warnings, but optionally to have warnings treated as errors, so builds will fail when documentation is absent, is a real help in finding holes. It doesn't help with creating good comments, but something is generally better than nothing.

And push back to management - every developer will tell you they don't have enough time to get things done, but if you can start baking in time to your estimates to include testing and documentation, even if it just turns "later today" into "tomorrow lunchtime" or similar, then you'll be reaping the dividends soon enough.

You'll also be teaching the junior some good practices and if you're both still around in a few years, that'll be a huge win too.

Answer 4

Since I've joined this company I've tried to push for better coding standards, project documentation, etc

If you're going to be the sole experienced developer left on the project this seems like a golden opportunity to introduce better coding practice.

Be open with the management team and explain the situation you're in, explain to them that you need time to work through the existing code-base before you continue kludging away on top of it.

It may seem daunting to tackle the code line by line without any comments, but afterwards your understanding of exactly how the software works will increase considerably, and you will find future additions a breeze to implement!

And lastly... sometimes a new job can be just the ticket, but 3 months into it you might find yourself in exactly the same position but with less influence over issues that matter (i.e. coding standards!).

Answer 5

If you quit and the department shuts down I wouldn't hold you responsible at all, assuming you are a recent addition to the company. But on the other hand, if you've been there more than say 6 months and there's anyone (at least, anyone important) who doesn't know what you think about the current standards then I'd hold you partially responsible.

It's not enough to simply say "we should comment our code" to your fellow developers. If the code is unmaintainable then it's your responsibility - i.e. part of your job - to ensure that everyone knows it from colleagues and teammates to management and support. If they don't care, then you either accept it or leave.

You didn't leave, so you implicitly accepted it. You don't say that you've been testing or commenting your own code, so I can only assume that you haven't. Now all that "technical debt" is coming home to roost. You have three options:

1. cut-and-run, find a new job. Presumably you'll do this on the sly whilst still working at the current job until something comes up. This is what you'd do if you think the problem is insurmountable, too risky, or too much hard work. Start looking immediately, because if the code is as you say then things might get ugly very quickly.
2. step up, position yourself as the new senior dev and fix the mess. You have the opportunity to prove yourself, if you are up to it. But I would attach some dependencies that have to happen before you invest yourself into the task
   • your management must understand that you are in a fix, things have not been done correctly and processes must change. You might have a hard time here if you have been part of the problem - if you've been there for a while then without a doubt your boss will say 'so why didn't you let me know this was happening?'
   • you get a promotion to senior dev, which should mean you get the authority to make things happen the way that you want. If they don't trust that you can do the job this won't happen.
3. do nothing. Just turn up and get paid like you've been doing so far, they'll hire someone else to be the senior dev who will be responsible for fixing the problem, don't stress it.

Answer 6

Code can always be manipulated into a testable state... It just depends on if you have the time!

I advise a read of Working Effectively with Legacy Code which will help you identify strategies for getting tests in place.

The temptation is to throw the whole lot away and re-start from scratch... This is nearly always the wrong thing to do (so says Joel Spolsky, so it must be true!).