I have been tasked with adding some new features to a legacy ASP.NET MVC2 project. The codebase is a disaster and I want to write these new features with some thought behind the implementation and not just throw these new features into the mess. I would like to introduce things like dependency injection and the orchestrator pattern; just to the code that I am going to write. I don't have enough time to try to refactor the entire system.

Is it OK to not be consistent with the rest of the codebase and add new features following different design principles? Should I not introduce new patterns and just get the features implemented?

I feel like it might be confusing to the next person to see parts of the system using a design that other parts are not following.

  • 1
    IMHO it is always better to consistently write features on a bad architecture than to introduce new complexity. – maple_shaft Jun 12 '12 at 22:22

I've been in a similar situation, and it's a tough decision. As you've pointed out, it would be nice to start cleaning up the code and (ideally) be able to clean it all up over time. On the other hand, it would be rather annoying for future developers to see these sore thumb in the code, regardless of how good the code is written.

In the situation I was in, I tried many different things. The code was, and still lis, horrible. Some of the changes I tried were drastic, and others were less so. But whenever I tried to refactor the code, I found that doing so would just make the code more complicated and harder to understand.

Ultimately I tried to find patterns that existed in the spaghetti. Once I identified a few, I started to simply formalize it. This required very little changes, because I was mostly adding interfaces and identifying areas of the code base that could be made a little more generic with out drastic changes. This turned out to work very well. Now the mess felt like it had a structure, and that alone made it easier to reason about.

If you can do this in one key area (probably related to the feature requests) and branch them out to similar areas of the code base, you'll leave the code just a little better than you found it, but with out turning the forest into a shopping mall.

Also, check out Code stinks! What do I do? on the Programmers Community Blog.


I think it's better that at least part of the system is written "correctly", rather than the whole system being consistent, but hard to use.

I would make notes that the unchanged code should be changed at some point (hopefully soon), and proceed to refactor things as you go along.

It's pretty unlikely that you would refactor the whole system in one go anyway, so it's ok if there are temporary moments of inconsistency, as long as you are going towards a cleaner codebase.


I would advise not letting the status quo dictate the future, generally speaking. While there is something to be said for continuity, there is really very little to be said for continuing to suck (pardon the expression). Any small advantage in readability/understandability by not introducing new development patterns is likely to be offset by the nature of the mess itself.

If there are a lot of other people working on the project, and they've worked in and contributed to the mess, then I think they need to see what "non-mess" looks like. If you never introduce "non-mess", nobody will have any example to follow other than mess. Good design has to start somewhere, and if you are clear in your purpose and good about explaining the philosophy, other parts of the code will start to align with your effort.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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