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?
There has been some good advice so far in this thread. The big thing to keep in mind is that all software goes through a lifecycle. First you design it, then you write it, then you maintain/enhance it. It's during the maintenance/enhancement phase that things get crufty, but that's OK. Only after things start to become crufty to the point of serious impediment should the major rewrites occur. (Tiny rewrites can occur at any time, but *architectural-level* rewrites should not.) Code maintenance can be compared to other types of maintenance; let's pick house maintenance as an example. Do you pay to have your house re-reroofed every 3 years, or repainted every year? No. To maintain your house in perfect condition at all times is simply too expensive. So it is with code. Having said that, keep in mind the difference between *tiny* rewrites and *architectural-level* rewrites. *Tiny* rewrites are ones that are not expensive, and may be compared to small but frequent house chores such as vacuuming, mowing the lawn, etc. *Architectural-level* rewrites are expensive, and may be compared to putting on a new roof or adding a new room. *Tiny* changes may be made casually, but *architectural-level* changes cannot be done so casually, or done that often. It's all about expense vs. benefit, and keep in mind that most code out there that works is not gorgeous code. That's the pragmatic reality.
Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
I've come across some truly horrific code in my days (I'm self-employed now, I still come across horrific code but it's mine dammit..) in $VBC and well, I had management refusing to allocate time and some people to fixing it up.
My view on it; if you think that code is going to break in new and interesting ways in a few weeks/months - fix it anyway. Do it on your own time if you have to, but keep track of how much time you do spend on it. Fix it on the side, but don't actually implement the fix. yet. Wait for the original code to break, watch management panic and basically walk in and say "i can fix it in (2*the-time-it-really-took) [days|weeks] -if- i get time, resources, and oh.. some days off".
first of all you already have the code waiting so you can now legitimately read slashdot all day (doing research), and you got your name in the good books - not to mention you're on your way to having a reputation as a miracle worker.
okay so some of you might not agree with this approach, but it's worked well for me, and it's a good way to pretty much tell your manager "you suck" without getting your ass kicked. (besides i like watching people squirm and having to explain to -their- bosses why stuff broke in the first place).
There is no sig...
Fred Brooks in _The_Mythical_Man_Month_ (should be required reading for any software engineer) said "Plan to throw one away. You will anyway." However, he was only talking about the initial design/impliment phase.
The real trick is distinguishing between code 'that is bad', and code 'that I think is bad', usually because I'm not used to how it goes about solving the problem. Learning to figure out what someone else's code is doing is the best skill you can aquire early in your working life. You'll be doing it a lot.
Zapman
I believe this means he wrote a really simple multitasking kernel that switched between two processes, compiling it on Minix but not using Minix code. Then he wanted to turn that simple 2-process kernel into a terminal emulator, which raised the question of drivers, and it was on its way to being a real kernel. (If you look at the Linux-activists archive (warning: 600K archive), early Linux seems much cruder than Minix, something which wouldn't have been the case if Linux == Minix being rewritten piece-by-piece.
I have found (at least in my situation in a large corp.) that in order for management to approve anything done, you need to give concrete dollar amount savings for anything you might feel is the "right thing to do".
I know this is hard sometimes to quantify, but in my experience, you can go on for hours with reasonable/logical arguements about why something should be done.And after all of this you get one question, "That's nice...how much $$$ will this save us over what we have now?"It's not so much the savings, but the immediate costs that are taken into account when making the decision whether to pursue something like this.
A way I got around this:
I recently had an idea for my immediate team that would save a few thousand dollars a year in production support. Instead of presenting it to my manager and listening to them saying that we can't afford to spend time on developing it now (usual B.S. from clueless managers), I just went ahead and starting working on my idea in those spare moments during the day, 15 minutes during lunch, etc.I presented it to them saying that this cost them next to nothing (since it was 90% done, and I wrapped the time into other tasks during the day), and it would be ready to implement in a matter of a few days.
You can try to take the credit early on for an idea, or you can work in your spare time to prove it can be done, and that you are willing to make it happen.The latter is what (whether unfortunately, or not) is what the suits will buy into.
Just one person's experience...
At least to your corporate masters it does. Ah yes I can picture the conversation now...
"If you code monkeys knew what the fuck you were doing in the first place you wouldn't be whining at me for more time. Go back and fix the shit you built as all fuck to begin with. Move!"
Whereas if you fix something, even if what you do it a piece of shit drive-by chunk of crap, then you're a fucking hero !
The customer won't notice or care about the difference and if it runs like shit blame it on the hardware or the sysadmins or the crappy db design. Or the H1B that touched it last.
Plus if you patch vs. rebuild you never have to hear from someone else that what you did was a horrible design.
That's what I would do if I were cynical but of course I'm not.
You can understand its function without understanding its implementation. For instance, if you program C, you know pretty well how "printf()" is supposed to work. If you then go open the hood on the printf implementation with intention of adding something to it (say, a new % operator) and discover it to be the biggest pile of rotten bits you've ever seen, then the 50/50 rule applies.
Often, it's much easier to figure out what the interface to a black box is than it is to understand the contents of the box when you open it.
--Joe--
Program Intellivision!
-- Seriously, though - it's very hard to rewrite a program from the ground up; somehow, it's never as good. I'd clean up the code, but not rewrite.
- This statement is wrong, just plain wrong. The axiom in computer science is "Don't fix bad code, rewrite it.
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...".
The fact of the matter is, the field of computer science doesn't really care, but the field of software engineering would. (If the algorithm was put into code form, that's generally good enough for computer scientists)
Woz
You have to compare (time to thrash thru bad code) with (time to rewrite + glide thru good code). Suppose it will take two months to rewrite cleanly; in two months, you will not move forward at all, but you will have a very clean base. From then on, progress will be twice as fast as using the old ugly code. Here it appears that 3 months is the breakeven time.
You also have to look at time to market. If your competitors will get to market in two months, then maybe it's better to get there at the same time with ugly code, rather than be a month later, even tho the later code could be enhanced and maintained much better than the competition.
Best you can do is work out the estimates, throw in priorities and market considerations, and take your best shot.
Try various degrees of cleanup. Maybe a moderate cleanup will take 2 weeks and double your efficiency. Maybe a thorough cleanuop will take two months but only quadruple your efficiency. Maybe you do the simple cleanup now, the fancy one six months later.
Compare it to freeway vs city streets. For short trips, the extra overhead of getting to and from the freeway doesn't make up for the longer travel time. Sometimes fast city streets are a good compromise between freeway and slow streets.
--
Infuriate left and right
It is definitely worth retooling code that is awful if
--G
A few things I would like to point out:
1- If you are maintaining code, you should not be refactoring code. There should be 'specific' bugs that you are fixing. Dont do more than this. If you do more than this, the additional changes must be tested, documented, etc. This is not the purpose of maintenance.
2- If the code is that bad, then propose refactoring to management and let them consider and delegate. It is highly unlikely that the developers doing maintenance will be the ones who design the refactored implementation.
Management hates refactoring because they have to justify and fund a project to provide the same functionality which currently exists (although in a much less glorius form)
Development entails not just coding, but testing, integration, documentation, etc, etc. The code part of the project is the smaller of the whole, which is why management may be relunctant, even if you say you can code the changes in a few months.
Yes 4.x was that bad (or haven't you ever used it?) -- After a gazillion point revisions, certain badly formed HTML 3.2 can still crash the thing, for example. Don't forget that they hacked on "Netscape 5" for about a year before coming to the conclusion that their old Mosaic-derived codebase was at the end of it's life.
The "particular function" in Netscape's case was the whole renderer. CSS had to work (not JSS and a bridge as in the case of NS4), DOM had to work (W3C, not layers as in the case of NS4). Even plain ol Netscape inventions such as tables had overhauled to work right. And. once they had committed to rewriting the renderer, it's understandable that they decided to shuck the other things that weren't making people happy (such as the Motif UI under Linux). What's unfortuante is that they didn't start the rewrite back in 1995, like Microsoft did with their Mosaic fork.
--
Business. Numbers. Money. People. Computer World.
Getting sufficent testing resources is the bottleneck in our company and paces our releases.
The upper management doesn't believe in hiring
lots of testers, and people don't like being
full-time testers for long.
Code redesign has to be aligned with testing resources.
Our company has a ratio of 1:4 testers:developers.
MicroSoft advises 1:1. However they have a
hundred as many customers as we do.
Might want to re-engineering your data abstractions (objects) and process flow.
In our yearly release cycles we try to get
in a months worth at the beginning of cycle.
Sometimes deceive the project manager and do
it under the guise of development.
A design cycle might be:
(1) Specification: one month
(2) Development: four months
(3) Testing & bug fixing: four months
(4) cleanup, shipping and vacations: one month
Sneak in refactoring between stages 1 & 2.
I try to rewrite individual sections to make them easy to reuse should the entire project need to be rewritten. So I can fix just the area I'm fixing now but do it in such a way that will work just as easily if I do get to redesign the whole thing. Eventually everything needs a fix or a new feature so you'll get to gradually redesign. This slow process also gives you time to come to your senses if your doing something weird. :)
:)
Also I often write my own versions in my spare work time or in my own time and make my own version. Then you can compare the two versions and if yours is better offer it to your boss to try. If he doesn't want it then keep it for later, he may want it eventually or you can reuse parts. If you wrote it in your spare time then you can make it opensource and/or sell it yourself.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
You report back to management what the cost implications of both methods are and let _them_ make a decision.
It's _their_ software, not yours and _they_ have to decide what to do with it.
_____
My Journal
We have a VP of somethingerother here who has a lot of pithy sayings outside his office door, the sort of thing you'd see in a Dilbert strip talking about teamwork, promptness, goals, and I think I'm going to be sick. But he did have one refreshing one which described "intrepreneurs". These are like entrepreneur's, but they're working inside of someone else's company instead of their own. I definitely fall under this category. Sounds as if you may, too.
One of the first things it tells you to do is to come to work every day ready to be fired. I believe in this. If you're fired for differing with your boss on the grounds of a technical topic that you are the expert on and he is not, then you're doing yourself a favor, and it will not reflect negatively on your career.
Another is that there's a difference between saying and doing, and doing should be done underground. Rewrite it without telling your boss. He can't appreciate the importance anyway, so there's no point in making a soap opera out of it.
We can all advise you on the importance of not mucking with code because so many newbies have the unquenchable desire to rewrite, but we're stereotyping you and don't know the actual score. You're the one who has to to deal with that hairball, so you know better than any of us what needs doing. Follow your instinct. Whether you're right or wrong, I gaurantee you that it will be a valuable learning experience.
Project both costs against the short term and the long term. What short and long-term constitute depends a lot on your company. I would say 3 months vs 18 months.
I'm a big fan of keeping parts of a system small and isolated, so they can be completely rewritten when needed without bringing the product down.
-m
--- Hot Shot City is particularly good.
However, this doesn't mean you can't do anything at all. I consider a couple things fairly safe:
eliminate all compiler warnings. Turn on all compiler warning options and either eliminate them or document (in the code) why they're not a problem. I can usually clean up over 2kloc/day and while 80% of the warnings are trivial (e.g., missing prototypes), a good 5-10% are latent bugs. Variables initialized with incompatible data, functions called with the wrong types of parameters, etc. This sounds incredibly stupid, yet I've repeatedly found "fragile" code becomes much more stable once compiler warnings are eliminated.
close memory leaks. Run the software under an instrumented "malloc" package that detects memory leaks -- and ensure that your code always releases all of the memory it allocates. (You might not be able to release code allocated by libraries you use.) There may not seem to be much value in this, but my experience has shown that the effort required to do this always results in improved code. You should also practice "data hygiene" if you do this - clear the data structures before deallocating them, so it's clear if you subsequently attempt to access a freed object.
An alternative approach is to profile the code and verify that there are equal numbers of fopen() and fclose() calls, equal numbers of malloc() and free() calls, etc.
profile the code and find the hot spots. Profile the code and look for the routines that are called most often. Does it make sense, or is this an indication of a particularly inefficient algorithm? Sometimes the code is written one way because of the limitations of legacy hardware, and now it's just a pointless waste of time. (E.g., I've seen routines that opened a file, read each line until the Nth line, the closed the file and incremented the counter! That might have been necessary 20 years ago, but I replaced it with a bit of code that mmap'd the file into memory and then did some pointer magic and shaved 25 _seconds_ off the startup time!)
prune dead code. Run the code through a call-tree routine and comment out all procedures and global variables which are never called. (I find it best to bracket the code with #if 0/#endif and tag each line with /**/ in the first few columns.) N.B., call-tree software can't find functions called indirectly through data structures! Repeat the process until you've found all procedures only called by procedures which are themselves uncalled, etc. Consider moving routines to other files, if it will allow you to make it static. I've found up to 2/3 of legacy code is now dead, and understanding the bit that remainds is *much* easier. Do not delete the "unused code" until a formal rewrite, however!
After all of this is done, the code may still be a undocumented ball of spaghetti, but it should be sufficiently organized for an intelligent decision whether it makes sense to rewrite subsections.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I work for a Java shop where we wrote a component which is kind of our 'flagship' (aka used by lots of customers).
:-)
The initial design was done by a moron, who is just out of Uni and who read too many UML design books, but never seen/written a real program. The code was
- over engineered
- threaded unnecessarily (java threads are easy to program)
- with layers and layers of abstraction.
- and ofcourse BUGGY.
He left and I got to be the poor bastard to support / maintain it. I hated his guts while doing this. But I have become quite an stealth programmer. I have learnt
- a lot of Java thread issues
- how to work around design flaws
- how to do a 'transparent' hack
I have lobbied manager for rewrittnig it. But never got the permission b/c of 'it is too big already / we cant justify the time to rewrite something within 6 months'.
FInally one of our customer who was using this program threatened to pull out of the deal if that component didn't do what it supposed. It took me a week alnighters to get that done. And every day every one from my manager to VP of Eng were on their toes!
After that I had permission to rewrite/design 'parts' of the program. So it is kind of a background process. During my design
- KISS (Keep It Short & Simple)
- avoiding all the pitfalls I have learnt
- unix philosophy (doing one thing & doing it well).
I also have a second programmer assigned, so design/coding decisions are analyzed well aswell.
In my opinion version 1.0 of a program should be simple and v2.0 can be a redesign considering all the user feedbacks.
And the best thing I have learnt is 'you get a design right, after you did that wrong'
LinuxLover
The subject says it all, really. :)
-*- Any technology indistinguishable from magic is insufficiently advanced -*-
"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?"
Simple. Do what I did. Give up. Spend all your time reading slashdot, working on pet projects, and learning cool new technologies that you might actually be able to use if and when you find a new, better job. I have literally refactored and rewritten this project I've been participating in several times. But I never have the guts to actually show my work, since it would obviously reveal my opinions of the current codebase. In contrast to the recent Ask Slashdot about finding beautiful code, I suggest you learn to live with unconscionable quagmirical morasses of code. Just put it out of your mind, or you will never get any sleep.
It's 10 PM. Do you know if you're un-American?
Just earlier today Reuters reported on incresingly shoddy water and sewer pipes across the country. Basically, some of the major cities are running on piping that's a century old. St. Louis' pipes predate the Civil War. Nobody wants to spend the money to fix them.
This quote from the article relates to code as well as water pipes: "Is the sky falling? No, the sky is not falling today but unless people start taking this more seriously, within 10 to 15 years the cost of addressing these problems is going to be even higher. It's not an issue you can ignore for long."
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Don't talk to management, ever, for any reason, until you read some Steve McConnell, such as Rapid Application Development: Taming Wild Software Schedules. Also, check out some of the stuff from SEI, such as Investment Analysis of Software Assets for Product Lines. If you're going to commit millions of dollars of your employer's money, you'd better have some research and data to back it up.
read the "mythical man-month". Its a good book written by ex-IBMer about when you should invest more and when you should walk out. First off expect the project to take 1.5x the amount of time. Secondly, putting more people on the job is not always the best solution. This book explains on how that can actually put you behind because the new addons need time to catch up with the rest. I thought it was a good book, I give it 2 thumbs up and a phat toe.
what is the definition of a coward? a man who thinks twice about fighting a lion. what is the definition of a braveman?
Make sure you understand the system first!
You mentioned that you are Junior developer.
Many re-design efforts start from not being
able to understand how system works.
True, but on one serious condition: The rewrite is done by the same person(s) as the original. When rewriting someone else's code, you are will have to map the other guys mental model from his source, form your own map of how things should be, and transform that into code. Much less effective than rewriting your own code, where you can reuse the mental map you built the first time, especially the parts you realized when it was too late to change, and had to kludge your code to work anyway.
In Murphy We Turst
At the very least be aware that "here there be dragons". More often than not when I run across some piece of code that makes me exclaim "What brain-damage is this?!?" I later discover that some other bletcherous mess is depending on that particular flavor of brain-damage.
If a piece of code has a tight enough interface specification that you can actually get away with the 'school-taught software-engineering, it's a black box we change the insides at will' mentality -- then chances are that code isn't crying out for a rewrite in the first place.
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
And if you don't know what the code's supposed to do, how can you recreate it?
--
So my advise is to only "stick your neck out" and "go the extra mile" if you really care about the code or project. If it feels like someone else "owns" the project and you're not in control of its direction, advocating and persusing a re-write is probably unwise.
PJRC: Electronic Projects, 8051 Microcontroller Tools
This argument really could go either way, depending on the size of the system in question. If it's small enough that you actually can understand almost all of it, then a rewrite will probably be superior to the first implementation. However, you're definitely right in asserting that a rewrite of something you don't really understand will turn out to be just as crummy as the original, but that's because you didn't really learn the subtleties of the problem space from the original. Rewriting something small can be a winning situation, but bigger systems will almost always be a nightmare. I think Netscape 6 would be a good example. Sure, it's finally getting good, what, 2 years after the rewrite began?
Just remember, when you're thinking about whether or not to do a rewrite: don't do what Netscape did ;)
If you've only maintained the system for a "few hours", I doubt you really understand the system well enough to pull off a redesign and rewrite. Not to mention that it'll be a hard sell to management.
I've seen new hire after new hire come into a company, look around at the steaming heap of code, and within a week want to rewrite it all. The best fun (as their underpaid "peer") is being supportive and getting them to go ahead and try it. It's fun watching wiseasses hang themselves.
On the other hand, almost every time I've done a rewrite like this, I kicked myself repeatedly for not doing it sooner. The only times I didn't? When I was that new wiseass that didn't really understand the system. I was slowly sucked into a downward spiral of rewriting more and more pieces until I scrapped it and hauled out the duct tape and chewing gum.
If you really want to pull off a rewrite, just go ahead and sneak it into your schedule. Don't bother trying to get management to understand the issues. They don't see things like you do. They're almost a different species. They figure once something is written and works, it's finished.
But sometimes you want to do a system that doesn't take 3 days to run. Oracle may be functional, but it's not quick.
Netscape is a bad example as it was basically pushed out of the market by Microsoft. The demise of Netscape would have happened whether they rewrote the code or not.
Actually, the adage "If it ain't broke, fix it 'til it is" works better here. When fixing it to make it do what you want breaks it, you need to redesign it. If you can fix it without breaking it, keep it.
It seems to me that your management wants you to keep fixing the system until it breaks, at which point you're allowed to replace it. If you honestly cannot fix it to work, rewrite it.
Some things to remember when rewriting, though:
You are in a maze of twisty little relative jumps, all alike.
I have been programming for a while now. I have seen a lot of ugly code. One thing about that ugly code sticks out at me: it was all ugly. It is remarkably odd. Funny how all *that* code was ugly but mine wasn't.
At this point in my career, I believe quite strongly that the only time you should rewrite is if you are changing to another language. Even then translation is often a good idea.
If it is in the same language, make it better. Is a method too long? Find some lines of code that represent a task and move them into another function. Would this one really big procedure work better as three classes? Peel off a class at a time. Refactor the heck out of it until you are happy. Test often. Code a little, test a little. Before you know it, that Pinto will start to look like a Porsche. At the same time, you'll keep all that knowledge that someone worked so hard to put into that code.
Refactoring isn't a new idea. Martin Fowler wrote a book about it and there are some sites on the internet if you look hard enough. The important thing about the book is that it is liberating. It was the first thing that ever suggested to me that I might try fixing bad code.
Rearchitecting might sound like the best answer, but be brave. Software engineering is often about maturity. Someone who always says "if the company isn't right then find another company" might be missing out on something. If you can help your company success, you just might find yourself succeeding.
They do this with heritage buildings as well.
;-)
oh, you meen like Win9X?
I am become Troll, destroyer of threads
It's important to remember that when you throw out old code, you can be throwing out hours of productivity and learned knowledge in the from of incorporated bugfixes.
Was is *really* important to throw out the ftp code in netscape that understood all 60 types of servers to connect to? surely there was something worth saving.
Yes, spaghetti code is nasty, but if developers spent more time reading the code they have on hand, re-use would be more prevalent.
An opinion is simply that, and I'm entitled to mine.
If you feel baited to flame me for a perspective that differs from your own, well then, that's more about you than me.
A host is a host from coast to coast, but no one uses a host that's close
Management doesn't usually listen to a junior engineer who says the system needs to be redesigned. Chances are they have a senior engineer who is already saying something and trying to echo it up to an Architect or CTO who has some sway.
That isn't a nice thing, but it is the truth. Lower management wants to avoid the ire of higher management. Generally they are going to say something to the effect of "Just get this one item working" because just that one piece will take a fraction of the time it would take to redesign the system. Does it matter that they are going to lose the time taken to redesign and then some over the course of months? No, it doesn't.
Ultimately there is someone who wants the software and they want it now, and they are not going to tolerate having to wait two months while the infrastructure is refactored. You can show upper management all the supporting evidence you want, but if doing this is going to seriously impact their short term cash flow (or any number of analogous tangible items) then they are going to want to hear how a bandaid fix can be implemented.
Yes it sucks, yes I live it. One skill that moves you up that Junior to Senior ladder is your skill at finding interesting bandages to treat a sick project.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
is when you get to the point you're at. If you see a problem, or realize that a redesign will make it better than just a little here and a little there, then you re-write it. It's your decision and not managements. On the other hand, they fund you so you'll have to convince them.
My karma's bigger than yours!
SIG: HUP
I strongly agree that you should talk to an employee or senior contractor and see what they think. Approach them about the technical side of this problem, but they may give you background about some non-technical or cultural reason for leaving this stuff alone. Unless you trust some one totally, don't ask why management won't let the stuff be changed- some people will twist that around to make you look like a trouble-maker or goof-off. Better approach them simply about the technical merits of rewriting this particular software. If you think that you need their support, before you ask them to back you up on this, be certain that that they are the kind of people who don't flake out on you - saving any e-mail is a good idea - but if they turn flaky there will be bad feelings that YOU could have avoided. And if you and Joe Blow haven't agreed that he will back you up on this, then don't tell management anything that Joe Blow said or implied. It may be true, but it just isn't a nice thing to do. There is a BIG difference between asking me what I think of some software and asking me if I want to get involved in your dealings with management. The first doesn't necessarily imply the second.
Worked with a really bright guy once, had an amusing story about his brother, another really bright guy, just a few circuits missing. Managed to convince management - through a very good looking cost benefit ananlysis study - that removing all documentation from the programs would save on storage and thus money. They bought it; he wrote the code that wiped out all comments; and they have had virtually zero new employees last a year before quitting in disgust (this for the last decade). The programs there are old, huge, and insanely modified/complex.
Yep, it's a gov't installation. Remember - most gov't employees are not paid for how well they do their job, they're paid for how many people they have (i.e. NEED!) working under them. This sorta qualifies as a negative incentive towards efficiency.
There is another reason - system performance. I'm not talking about stability - that should be part of any working program. I'm talking about things like actual run-time, memory usage, storage usage, and the like. I once worked at a company that had a very narrow batch window (8:00 p.m. California to 5:00 a.m. London), and was starting to get seriously concerned about programs which, due to the huge increases in number of records processed, was starting to exceed that window. Re-writes were ordered, and hours shaved off a number of the largest programs. Another I worked at had a program that built a DB (RedBrick) from nine different user-supplied files. All initially on tape. With 5 or six of them less than a thousand records (the rest were around the 100 million count). The original program could be using up to nine different tape drives, and ran for eight hours. Loading the 5 or so files into memory dropped run time to under an hour.
You _can_ generally sell management on a rewrite if you can cost justify it to them. Most places are scarce on personnel resources, which kinda conflicts, but telling the management that a week of your time will save x odd hundred thou a year tends to make them perk up and listen.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
It may be that you just don't understand it to the core yet. The one thing that I hate is taking over something that somebody else wrote. My way of definig variables, writing comments or use of a case statement might be different from another persons. More often than not just adding comments to what is already there helps fix problems like those mentioned. So before you go back to the drawing board, learn what has already been done. It may be brilliant.
I spent a few years doing PL/I in a mainframe application that bills about $6,000,000,000/year, so please believe me when I say I know how you feel.
Long story short: been there, done that, should have bought the T-shirt ... and very nearly got fired. I learned the hard way that they don't pay you to make it look pretty or even to make it run more efficiently. THEY PAY YOU TO MAKE THE DATE.
Trust me: this is the kind of medicine that it's best to take in very small doses: I know how frustrating it can be to have to wade through a mess that someone else left behind, but try to stay detached and avoid the temptation to reinvent the wheel. As other have pointed out, you can improve small sections of the code, one release at a time, and you'll have 80 percent of the possible improvement done in 20 percent of the time a rewrite would take.
Here's some free advice: the next time the urge strikes, just take a walk around the floor, and remember that everyone else has felt the same way at one time or another. Then, get back to work and make your date, because that's what pros do, and it's all anyone will ever remember.
Then, go home on time, help your kids with their homework, and rest assured that you're doing a lot more to make the future better than you could ever do trying to re-re-rewrite some piece of spaghetti. As for the rest: that's what optimizing compilers are for, you know?
Bellhead
...who started out with Minix and gradually replaced code until none of the original was left. You're right, though, the result does resemble UNIX an awful lot.
Brackets contain world's first nanosig, highly magnified:[.]
There may never have been any minix code in any version of linux distributed as such, but by his own words, when Linus began writing Linux he started with the Minix codebase and worked by replacing it piece by piece. By the time he got around to showing it to other Minix users there was no Minix code left, but that's how he started. He actually used this as an example of how you can approach a seemingly huge project when there is something inadequate but similar to use as a starting platform.
Stop showing your ignorance.
Brackets contain world's first nanosig, highly magnified:[.]
If management doesn't seem interested by conversation, make a proposal/report. Nearly everyone in high school, anywhere, had to write one sometime. It would take a couple hours to make a concise explanation of the reasons and a written copy is always taken more seriously than a mention in the breakroom or a random e-mail. Keeping good records, taking initiative, acting proactively, and carrying yourself professionally gets you noticed and promoted.
Most importantly... it covers your ass when people ask later why you didn't fix the problem months ago.
Never been in a company where people would leave rather than work on the existing codebase? At times like that, management might reconsider. And if it's going to take such a dire emergency before they do consider rewriting the codebase, they're lousy managers.
I didn't pay for my operating system either
Go ahead and refactor; but for god's sake, don't dump & rewrite! Look at this for further explanation
It's amazing how local transformations can introduce quality to systems with no conceptual integrity.
But to really be effective, you have to be aware of where you started and where you are headed. The big picture is a lot of little pictures, hopefully connected by a coherent architecture.
One of the best ways to move toward coherent architectures is to start thinking in terms of design by contract. Think of preconditions, postconditions, and invariants as part of the public interface, just like routines' signatures. If your language doesn't support them directly, you can probably get free 3rd party tools that will help. Even if you can't, put them in as comments. Program code is documentation of the write once, read many times, variety.
Learn and get comfortable with as many variants of as many patterns as you can. When you use them, mention them in your comments.
This anonymous coward is Tom Morrisette
Over the course of the next year or two as I maintained this utility I began by rewriting individual routines and then moved to modifying small sections of code in the end there were probably only a handful of the routines in the codebase that hadn't been completely rewritten.
If you cannot do that, then perhaps you are the one that needs the adjustment.
--
Sorry, but I have to take issue with this:
;) developers should always be weary of what Brooks calls the "Second System Effect", whereby needless features and are added. More info on that here.
Seriously, though - it's very hard to rewrite a program from the ground up; somehow, it's never as good. I'd clean up the code, but not rewrite.
This statement is wrong, just plain wrong. The axiom in computer science is "Don't fix bad code, rewrite it. Yes, I realize that's the CS take on things, and that it doesn't always jive with business needs. But I digress.
Second systems are typically easier to write because the hard part is already done: transforming the mental model of the system into real, working code. Plus, you get the benefit of lifting out portions of the old code that are worth saving. Also, second systems are easier to write because the entire idea has been realized via code once, and that means that you should see patterns and behavior that were not obvious when the initial coding began.
OTOH (because I like to argue, even with myself
A lot of programmers start out re-writing with good intentions but usually wind up with something just as bad as what was originally there.
In order to avoid this problem, the programmer must analyze the code and have an intimate knowledge of what the code does and what it is SUPPOSED to do. After looking at these two things, the programmer must analyze what the impact is going to be for both fixing the code and replacing the code.
Once you have this information you can then assess the risks involved with both approaches. The programmer should also be aware of what the long term goals of development are. Its possible that you could be rewriting a section of code that will no longer be used in the next release. This would be a waste of your time as well as the companies.
One of the largest risks of rewriting a section of code is that you may change the intent of that code or introduce new side effects that you hadn't thought of. If the code has been around for a long time, chances are, that code for the most part works and should only be fixed. If the code has never worked, then it could be a good candidate for re-write.
When we fix bugs where I work, we are required to fill out a Design Change Request (DCR) form for anything that requires significant modification to the structure of the code. If it's a simple fix, then we fix it. The DCR is then submitted to a manager and they review it and approve it. In the DCR you state what problem you are trying to fix, what files it affects, what you plan to do, what side effects it might have, and any other alternative solutions that might be feasible as well.
What a DCR does for the programmer is it gets them to look at the problem in detail, and to understand what impact their solution may have. It also gets the programmer to look at alternative ways of solving the problem.
I can't count the number of times I've switched solutions because I thought of a better approach. Had I just started in and started fixing and or replacing code, I would have been wasting time and energy on something that might not have worked in the long run.
The last thing I want to say, is that Documentation and Planning for Change are critical to an application that is going to be easy to maintain down the road. Documentation (i.e. Good Comments) are not for you, but for that poor sap that follows you. Help them out!
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
When it is really time to rewrite a product, management will be willing. This is because it will be truly more expensive or impossible to get the functionality requested by management out of the old code base.
Until then, they are correct in their judgement that it doesn't need rewriting. Elegance doesnt pay your salery.
When you need to improve a section, learn what the code does, and if you must, rewrite the section. Keep the general system in place. Designing a system is more fun than debugging an old one, but your new system will be just as painful as the old one is.
In 5-7 years, the programming style you use will look ugly and primitive compared to whatever the latest buzzword in computer science is. If you rewrite whenever something "looks ugly" then you will be perpetually redesigning, and that isn't an efficient use of corporate resources.
Tonight I rewrote some code that traversed a tree depth-first in reverse. The old code wasn't working right, and it was too ugly to see by examination what was wrong. Rather than debug it, I wrote a class that represented position in the tree, with "next" and "prev" methods. The tree-traversal function then became much simpler.
If they ask you for maintenance, give them the gory numbers for effort-required, especially after you spent some time understanding it (show them the bill for that time too). At some point they'll go, "You know, maybe it's time we cleaned that code up."
A friend of mine once rewrote the core of the application he was supporting by replacing bits and pieces here and there until he installed the new architecture from the inside-out. They do this with heritage buildings as well.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
One, go in there, convince upper management, and rewrite the whole thing.
Two, add another layer of obfuscated code on top so you can get hired back as a consultant when the whole thing goes belly up and no-one can understand it.
Three, perform an 'accidental' disk wipe and force a code rewrite.
Seriously, though - it's very hard to rewrite a program from the ground up; somehow, it's never as good. I'd clean up the code, but not rewrite.
You might pay particular attention to his habit of writing unit tests before he does anything.
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.
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.