Slashdot Mirror
When Should You Go Back To The Drawing Board?
Prozzaks asks: "As junior developers, one of the task we will likely be called to do in a company is system maintenance (updating, bugfixing, adding functions to a existing system). I've already had a situation where it was necessary to do some maintenance, and after working a few hours on the system, I realized I was redesigning it from the ground up. The problem is that companies don't want to allocate the necessary resources to redesign a system. What are we to do when we discover code in the companies products that -really- needs a rewrite and management staunchly refuses to realize this fact?" There are times when I can understand the desire to go in and rip out code that you feel isn't operating as well as it could, and there are times when you have to sit back and weigh the benefits of a rewrite against any possible gains. The adage "If it ain't broke, don't fix it," applies here, but there are times when badly designed code that works now, will break later. Under what situations are rewrites necessary, and how can you get management to understand the need if it arises?
The only point to going back to re-doing something is if the users are ready for a significantly enhanced product. If the thing they have is working well enough for them, you're going to get zero support for an effort to clean up the code, even if it will reduce maintenance work in the long run. Clean bits here and there while you fix other bugs, but a complete rewrite is only warranted if the software system is really not meeting current requirements.
Energy: time to change the picture.
There is NO WAY you should do this.
If you are doing bugfixes, fix the bug.
If you are planning a rewrite, or find yourself rewriting major portions of the code, you are making a terrible mistake.
One, if you have to rewrite major portions, it was improperly designed in the beginning. This means a group of people, familiar with the task at hand, did not sit down and do a proper design. Note that you are not doing it either!
I don't know many times I've seen people start debugging and rewrite the code, and the next person sees it, says its all junk, and rewrites the code, ad infinitum.
Don't do it unless your serious, and if you are serious you need to be much more formal about it after the bug fixing is done.
BTW, has anyone else noticed what appears to be a pengiun sticker on the back of Johnny Depp's guitar in the "Chocolat" movie?
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
The best way to keep software clean over time is to redesign parts when you add functionality, otherwise things will only get worse over time. Tell management that it is called refactoring, if you think that helps. The wonderful fact about redesigning when needed is that you can do as little or as much of it as time and budget allows. And whenever you feel it is necessary.
The important thing is to stay in contact with management. Typically, you will be fixing a bug, or adding some functionality. In order to do that, you will often need to understand a component really good. At that point, you can tell the management that the chosen component, which you now understand perfectly, is a big mess. Tell them that since you have worked with it for over almost a month now, you know it's in and out's perfectly, and that you have some ideas for a better design. Tell them that you don't want to rewrite it all, because that would be to costly, but that there are some parts especially crufty, that it would be better to rewrite, and you would like to do just that. You can even tell them that it would probably be cheaper to to that then to just add your cruft to the other cruft, as it is probably true.
But don't lie to the management! Be honest, and tell them exactly why something needs a rewrite. There is very rarely a need for a total rewrite! Most code that exists are there for a reason! Sure, it can be cut&paste code (modularize), it can be deeply nested long blocks of hard-to-understand code (modularize), and it can be ugly non-portable code (clean up). All these are good reasons for a minor redesign.
But whatever you do, don't redo it all! Unless you wrote the program yourself, chances are that you will not do a better job than the previous guy! It might be hard to accept for someone who used to be a hot-shot programmer at the university, but there do exist other good programmers than yourself!
If management resists a total rewrite, then they are acting sensibly. While you don't understand all of the code, chances are that most of it is there for a reason. Even rewriting a single component from scratch is more than likely going over your head. The company is more interested in keeping software working than in having to do new regression tests three times over because your new module didn't work exactly up to specs.
And trust me, if you think coding is expensive, I tell you what, testing ill-designed components (which they have to be, given that you only redesigned a small part) is very expensive. And if the software is mission-critical (which it often is), or it is sold to actual customers, it will get even costier.
So, just grab a beer, start coding, and be thankful that you can at least make a small bit of the cruftiness disappear. If you want something else, you'd better wait untill you've proven yourself for the company, or start for yourself.