Stable System Vs Better Design

Question

In may Daily Job i come across this Dilemma :

"Stable System Vs Better Design"

In routine job when i am fixing some module, When i see bad design

-> Badly written code

-> Badly Written Algorithm

-> Optimization possible

I would prefer to fix these also along with issue i am fixing

But many people opposes my changes a few supports, People who opposes will say

"You should be business oriented if system is stable, If you change some thing may cause regression, Hence do not favor business"

some time :

you will see your own written code after 6 months, Always you will see some improvment opportunity in this

While who support will say:

This is continual improvement and system will be more stable

So i would like to know what you people think

Answer 1

If applicable, write a unit test (or several, to cover edge cases). This gives you the confidence to refactor and know that you haven't broken anything.

Of course, if the code is tightly coupled (or spaghetti!), that's going to be a problem.

Answer 2

My opinion would be not to fix the old code if it looks not perfect unless the way it is written is interfering with your current task at hand.

Most of the code is written badly. It is a matter of fact. If you're not in a perfect team with the perfect understanding of quality value and the agreement on the approach to achieve and keep this quality level, your optimizations will not change the big picture. You may fix something now but the next guy will make the mess of the things again.

Answer 3

I have came to the conclusion that in this industry if its not broken, don't fix it unless there is a damn good reason to.

Answer 4

If it ain't broken don't fix it - wrap it. Isolate the modules as much as you can without changing its implementation; they should be touched (fixed, improved) when / if a real need arises.

Answer 5

I personally have a tendency to spend time fixing stuff rather than getting on with the required task. Unfortunately it is all too easy to start fixing what looks like an easy problem and unravelling a huge mess that you then wish you hadn't.

I have also worked with people who are the other way round, and can live with the bad bits as long as it gets the job done.

More often than not, you can spend ages 'getting something right' to make it easier to work with in the future and you'll find that code is never reused in the future.

I think the main thing is to have a balance of views on your team, discuss things regularly with others and ultimately, meet the requirements for your project, since it's the customer paying the bills.

Be constructive about any problems you find - don't just pick holes for the sake of it! Team code reviews help improve bad code over time as poor coders will start to understand how to make good code.

I would advise marking bad code with 'TODO' comments and then coming back to fix it later time/budget allows. At least you've got a flag for potential problem areas then, without having to (possibly) waste time on a fix that's not required there and then.

Answer 6

If you know the application inside out, or have comprehensive unit tests and time to test the application in a non-productive environment, go for it. Otherwise, do it just when it's necessary.

Answer 7

Both are correct and there is no easy way out.

If you don't fix problems as you encounter them, not all problems will be fixed.

If you break something with a fix that is not 100% related to the issue you're currently working on, then people will hate you.

On the other hand, if you fix some innocent code (or rather code that looks innocent) and it breaks in unexpected ways, you've found something valuable: Brittle code. Brittle code is usually something that no one dares to touch. But to make your product more stable, you must get rid of such code. The first step on this road is to find it.

I have to admit that such fixes cause a lot of "unnecessary" friction in the team. People will yell at you when you touch brittle code because they are afraid. Often, this code will blow into the face of your customers, so you will get heat from all kinds of directions.

So it really depends on how much pain you want to cause and what you're willing to endure. If you fix everything as you encounter it, the code will be better by the end of the year. But it often is worse by the end of the day.

Answer 8

I want to second all the "if it ain't broke, don't fix it" answers, but with a relevant link...

Things You Should Never Do, Part 1 - Joel Spolsky

In essence - sometimes that incomprehensible code is actually a necessary bugfix that you have no chance to understand.

Answer 9

On the one hand, changing code that's already more-or-less working can run the risk of breaking things, and it can easily become an all-consuming task.

On the other hand, leaving bad code alone for fear of breaking things can stifle new development, due to the burden of maintaining bad code.

Sometimes code looks bad because it has to deal with complicated corner cases, as Joel Spolsky points out, and rewriting it will create bugs by failing to cover those corner cases. Sometimes code looks bad because it really is bad, and rewriting it can fix bugs that you didn't even know were there. Experience with your code base should help you determine which code is which.

In Boy Scout Check-Ins, Jeff Moser discusses the idea of "always leaving the campground cleaner than you found it." Always leave the codebase cleaner than you found it, even if you can't fix everything; those little improvements add up over time.

As was said in this answer, unit tests are a good thing. Working Effectively with Legacy Code, by Michael Feathers, is a great resource on this topic.