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?
Bullshit. At least one company i used to work for would NEVER condone a rewrite. It didn't matter that the product started out as a demo in '92. It didn't matter that ALL of the developers were demanding a rewrite. it didn't even matter when they lost their two senior developers over this. They refused to acknowledge that some things just couldn't be done. In short, i don't think that you can always count on management to be reasonable. You may be in a case that no matter what you do, they will NEVER let you rewrite. So, i think you either have to accept that possibility, or start thinking about jumping ship.
"I don't need a compass to tell me which way the wind shines." - Mr. Furious, Mystery Men
1. Tell my manager about the nasty convoluted code.
2. Told her I could rewrite it, or try to hack what's there.
3. I Told here that in the long run it WOULD need to be rewritten, but then again it was a short term project, and I could probably make what was there work.
She decided that since we we're at feature complete, (about 2 months from shipping) It would be better for me to just hack at it. So I did, it worked out ok, I learned more about what the previous guy was doing and managed to work with it.
Sometimes there's code that no one likes, even the author. I think a lot of people have natural attraction toward rewriting something then learn and deal with what's out there. Personally I didn't care what my managers decision was, It wasn't my call, my job is to write the code for the tasks she gives me. Not to take on big projects that will risk the ship date.
-Jon
Streamripper
this is my sig.
May I ask where you studied computer science? Rest assured, that is not what I've learnt. I didn't think computer science had an answer to this at all, and if it had, I would guess it would be something like "Interesting problem, let's conduct a study by doing both...".
Anyway, it is impossible to give advice about this in a general way, because each messy system is different, and messy is sort of hard to classify anyway! But I think the original posters advice was right on!
In a real-world project there are lots of code that doesn't seem to serve any purpose at all. But trust me, most of it does have some purpose, it might be a bugfix, some tweak requested by users, a kludge fixing some problems with third-party software, or even hardware, or just something really smart that you'd never understand anyway.
By reimplementing something from scratch, the new program has to work just as good as the old one (from a users standpoint). And first when your users complain that you find out that many of those small uninteresting tidpits needs to be in the new version as well. Which makes the new version almost as dull as the previous...
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.