|
|
I know exactly what you're on about. I want to rewrite everything by others and myself the whole time. I think there are several aspects to this. Things are always very simple to start with and there's an appeal of a clean sheet while ideas are fresh in your mind. You don't have to concern yourself with mundane bugs in mature code this way.
Then there's the anything not 'done right' which can mean anything not done the exact way you'd do it. This requires a rewrite.
It's easy to link any bug to things not being 'done right' and to unfairly assess the code. Project is poor and requires a rewrite.
Comments on a new line start with a capital letter, or worse yet Pascal naming of local variable, or worse still camel cased function name. This requires a rewrite.
If I don't understand it, that's because the design is too complex and requires a rewrite.
Any class with the word 'Helper' in it should be removed and the whole system rewritten.
Anybody who uses the 'var' keyword in C# has no respect for clearing stating their type and should not be trusted in the field of OOD. Their code requires a rewrite.
I could go on for hours, but usually its just quicker to rewrite it.
Regards,
Rob Philpott.
|
|
|
|
|
|
I have a namespace Helper in which all my "swiss army knife"-functions are send to the bottom 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I totally agree.
I tend to spot one thing the previous guy (or gal) has done wrong, and used that as justification to try and convince myself I should rewrite the rest also.
As I get more experienced I am getting better as resisting this urge...mostly.
|
|
|
|
|
5.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
My guess is that Rewriting the code is understanding the problem (task, use case)
PS: I dont like rewriting, but I am a big reformatter: All new names, operators, spaces and a whole bunch of brackets
ie "legacy code"
int n = 0;
if(!n)
n++;
"my code"
int counter = 0;
if( counter == 0 )
{
counter++;
}
else
{
DebugOut("Error");
}
makes 8 of 3 lines. But better
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I'm aware of this tendency in myself, and have resisted it in the past. But.
There are times when a rewrite is necessary and appropriate.
During the last couple of years I've spent about a third of my time rewriting most of the code written by a former employee. It was barely functional, and responsible for far more than its fair share of issues in the bug data base. The essential problem was that this employee didn't give a rat's ass about the quality of his work. We're a Windows shop, using Microsoft tools, and he hated it. He wanted to be writing iThing apps instead. The end result was that he spent the last couple of years he worked here putting forth the minimum effort and producing crap that fell over at the drop of a hat.
I liked the guy personally, but professionally his standards sucked.
Software Zen: delete this;
|
|
|
|
|
Then you phrased the question wrong, you should've asked what we'd want to do. 99% of the time you're only going to be given enough budget to do maintenance; meaning a rewrite it out of the question regardless of if the code needs it or if we want to do it anyway...
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Yes it like wearing some else underpants
|
|
|
|
|
It's like a car mechanic that buys a car for his friend from a stranger. I want to deliver the best and have my friend (boss) assured that the car (code) is either working, or my own fault. It can't be someone else's faulty car (code) and also my responsibility. So I need to check the thing before I can guarantee quality. If I don't understand the inner workings, I'm obviously not able to be confident about it. Therefore I need to make sure it satisfies my level of quality first to guarantee my responsibility later. So I would say
6) To become responsible for that code, you've to know it's OK to the point it's faster to write it yourself.
...or you can always make a quick dirty fix and blame the original author (because it would be technically his fault). That's also option. 
regards,
Kate
|
|
|
|
|
Oh, when I inherit code, I always want to rewrite it. Usually I end up doing so, but not always, and almost never right away.
Chris Maunder wrote: code has a shelf life and by the time it's handed off it's obsolete (the job security approach)
This. Usually once I'm hired it's because my predecessor has gotten sick of maintaining spaghetti code and has abandoned ship. Nothing against their skills, but it's the natural course of evolution for any software project in this environment. I work right on the trading desk, so there's a constant stream of requests that all need to be done yesterday. You try to push back against it, to give yourself time to build things cleanly, but every once in a while something slips through and the code base frays a little at the edges.
Sooner or later, it's going to be a mess, and it's going to need a rewrite.
The trick is to break things down and know what needs a rewrite and what doesn't. As they say, if it ain't broke, don't fix it. If you can salvage it with a few minor tweaks, do so. Rewriting only becomes the right choice when it would take longer to make the change than to replace the whole thing. And that's only after completely learning the old code base. Even if you're replacing it, you still have to understand it.
And most importantly... When you find something in the old code that looks completely backwards and illogical, so crazy that no programmer with half a brain would have written... Maybe they had a good reason that you just don't understand yet. (I've fallen into that trap before).
But hey, once you understand the old code and decide it's beyond patching, you've got 20/20 hindsight and can redesign it while taking into account all of the nasty hacks that broke the previous design! And years from now, your successor(s) will do the same thing to your code!
EDIT: Oh, to the survey topic... If you don't know the language, LEARN IT. ALL OF IT. Even if you're going to rewrite it, you can't fully understand the code unless you understand the language, and you can't properly rewrite something you don't understand.
|
|
|
|
|
Otherwise I'd hand it off if possible; if not, I might be looking for another job.
But, seriously, it all depends on context, deadlines, and what is involved in the task at hand: is it maintenance of something that is not working now; a required port of something that's not usable now.
cheers, Bill
“I'm an artist: it's self evident that word implies looking for something all the time without ever finding it in full. It is the opposite of saying : ‘I know all about it. I've already found it.’
As far as I'm concerned, the word means: ‘I am looking. I am hunting for it. I am deeply involved.’” Vincent Van Gogh
|
|
|
|
|
I once got a project for VB and converted it to C# using an online tool.
Even though it had Crystal Reports in VB, I worked around it by re-adding the RPT files manually.
Of course the code was still terrible, but I think I saved a lot of time!
|
|
|
|
|
I am sure that the code was terrible because of the previous programmers, not because of the language...
That said there are few good VB.Net programmers out there 
Kris
|
|
|
|
|
OK, but then your COBOL rewrite is going to be rewritten again...
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Am I going to be doing extensive work on it, or just an occasional fixup for a few hours a month? The latter case tends to learning just enough to get the job done.
Is the tech something new and fashionable, or either scary legacy crap or limited enough in use that it's always going to remain obscure? Again the latter argues to only learning the minimum needed.
If I'm going to be doing substantial amounts of work on the system: are the tools in active development and work well with modern OSes and is the code base in decent shape; or are they unholy cluster-elephants? Only the latter case justifies doing a substantial rewrite.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Depends. If inherited code is the "mission critical" part of the software, I'll learn the new language inside-out. If it is a minor build script, I'll learn just enough to survive.
|
|
|
|
|
|
My not familiar? What does that mean? Editors, please consider changing the title of the survey to:
"You inherit code in an unfamiliar language. Do you..."
/ravi
|
|
|
|
|
You're observations are duly noted... 
|
|
|
|
|
I think your being sarcastic.
/ravi
|
|
|
|
|
Your more astute than I thought... 
|
|
|
|
|
If it's VB I learn just enough to do the job then hide in shame.
If first you don't succeed, hide all evidence you ever tried!
|
|
|
|
|
Well it's certainly not the English I was taught at school!! 
Quote: ...in a language your not familiar.
Let me fix that for you ...
Quote: ...in a language you're not familiar with.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
