How to deal with great products written with crappy code ?

Question

I was asked to improve and maintain an internal Web application used and approved by an important community of users. This includes performance improvements and adding features.

Unfortunately, the code is bloated, sometimes very poorly written, and hard to read and change. This makes changes much more difficult to implement.

Despite all of this, the application is good-looking, useful, and users like it and want changes.

That's why I feel like I have been fooled. Is it really better to write crappy code for quicker great result and glory, then leave for great new projects leaving such an amount of problems behind ?

I have read a lot about this topic on Coding Horror already, but I would like to read more from people here who are experiencing this sad reality, and how they are dealing with it. I might probably need to be given some courage too ;)

As my primary language is not English, please feel free to rewrite this question with better grammar.

Answer 1

Write a test suite for the product so you can be more confident you're not breaking anything.

Then refactor the worst bits of the code, or the bits you need to change anyway.

But: consider "if it ain't broke, don't fix it", If an area is working, and you don't need to change it, consider whether the risks of introducing problems exceed the benefit from making it "nice".

And find the original developers and tempt them into some dark alley :) Or better, make them do the changes

Answer 2

Yes, some badly written programs are popular. The downside is that such apps tend to be harder to improve over time (for example in terms of scaling, adding new features, bugfixing etc).

But no, it's not good to write rubbish code. It's good to identify what users want and give them a good interface etc and make the code easy to maintain. Occasionally that may mean that the users will have a wait a bit longer for new features, particularly early on - but you'll be able to get more done in the long run.

In your case, I suggest you try to improve a bit at a time. If you can, carve out one area and "fix" that, and make sure it never goes back to the "bad old days". Then carve out the next area, etc. Eventually you'll have a nicely written app. It may well take longer doing that than rewriting from scratch, but you'll be able to give users improvements as you go, and you'll have more confidence in it being a working system at any one point in time.

Answer 3

Almost every developer, ever, everywhere, when introduced to some code they didn't write, wants to rewrite it to fix the crappy bits.

Resist your urge to rewrite everything, fix the bits which are broken. Deal with bits which are unmaintainable when you have to maintain them!

Answer 4

Bad code is technical debt; it can be less expensive to write, but becomes much more expensive to maintain (unless you pay back the debt by refactoring or rewriting).

You might get a quicker result and glory, but when users later want changes, you will have to spend progressively more effort doing them (or fixing the unavoidable bugs).

Answer 5

I have written crappy code for some projects. However sensible 'bad' code. Crappy code can be caused by many reasons, not just the skills of the person.( well, most of time it is because of the skills)

Programmers can write very good code if you got enough time and no pressure from the business. However the business people do not appreciate the good coding but the functionalities and appearance. I consider that 'crappy' coder is a smart guy in the business. Simply he developed the solution model, get the software up-running in a short time and also made the employer happy I guess!! If let the coder write it again, he/she can do it much better.

Firstly, you need to convince yourself to appreciate how many stuff the early coders had been through, this is one of the points to consider if you are a mature developer or not. MOST of the people complaints and even laugh at the existing versions because they know they can do it better. It is like drawing on a blank paper with your imagination, or make a replica of the existing painting. Which one is more difficult??

Secondly, look into the code overall and find out where it can be improved, you may find something you misunderstood.

Thirdly, road-map the enhancement, it can contain recent and future TODOs

Lastly, start planning how it can be improved if you design it from scratch, new architecture etc, and present it to the management when it is ready and comprehensive.

Every software got a room to improve, that is why you got hired to improve it.

Answer 6

Make sure your management and users know that the code has insufficient quality from the changeability point of view. When estimating how much time you need to implement new features, always make explicit how much time you need to clean up the affected code.

Answer 7

"Despite of this, the application is good looking, usefull, and users like it and want changes"

The application is obviously giving customers what they want, but sounds like it has reached the unmaintainable stage.

I think there is nothing else for it but to refactor relentlessly. This will probably be easier and less painful if you resist pressure to add any non-trivial functionality simultaneously. By all means tell managers that though the software is good, it is in danger of turning into one big pile of unmaintainable crud.

Making code improvements often introduces one or two bugs of their own, but will save you a lot of brain damage in the long run. Get as many extra eyeballs as you can to help with testing and debugging, and stick to doing the really bad bits first.

Consider introducing unit tests if the previous incumbent have not yet done so, so that you have greater confidence that the refactoring has not broken anything. I don't advocate the 'if it aint broke...' philosophy as this will keep you on the same unsatisfactory merry-go-round.

Don't worry about your English, it made perfect sense to me and your predicament is universal.

Answer 8

This will happen to most programmers. The first urge is to rewrite it. The better approach is to just do what you are being asked to do. If you go into major rewrites you are very likely to break it.

If the changes required are simple you should implement them with as few changes as a possible, in the style that it is already written in.

If the changes are more complicated, then try to apply your changes in as few places as possible. If your plan is to clean up the code over time this is the place to start. Be careful of the changes you make, because you can easily break dependencies you don't understand. It's been my personal experience that I can usually add new features or implement changes by actually removing code and rewriting what's left in any given routine or method.

Resist your temptation to rewrite everything. Look at it as triage. Prioritize changes you would like to see and implement them as you implement changes that are being asked. Avoid affecting code that you are not being asked to change. Don't force your users to deal with problems from changes you are making just because of aesthetics.

Answer 9

Sometimes when a programmer picks up an old project for the first time and sees all of the classes, interfaces, code modules, etc. immediately think it's "bloated". In fact, it could be just have a very in-depth architecture, which can be overwhelming at first. If there's no documentation with the project (eg a Class Diagram), take some time to sketch that out. It'll not only help you understand how the project works, but also help anyone that follows behind you.

That also goes for statements such as "hard to read". If you know the programming language, then it's not any more difficult to read as any other application. The original programmer's style may be different than yours but if the application works, then they're not doing anything that the language won't let them do. The flow may be difficult to follow, but that can be overcome by sketching out the process (eg a Flow Chart). Most managers will allow time for a learning curve to become familiar with the application before making changes. Take that time to sketch out some diagrams, you (and the programmer that follows you) will be glad you did.

As far as "crappy code" goes, that's very subjective. Is it really the code (the implementation) that's "crappy" or the design? Is there a lack of design patterns? An overuse, or bad implementation, of design patterns? Or did they really implement solid design patterns but you're just not familiar with them enough to recognize them?

The point is, it can be overwhelming when handed a new project to maintain and it's easy to blame the original programmer for "bloat", "crappy code", "hard to read and make changes", etc. Sometimes that is indeed true, but many times it can be because the programmer doesn't understand the design and architecture of the application, or understand why certain things were implemented the way they were.