|
If I have to maintain it, then I'll try to pass the buck.
I can see if the language looks interesting or if it's a must know, then I'll take answer one.
|
|
|
|
|
I would like "to learn the new language inside and out and get to work",
if I don't like what I see when I get into matter (sadly it is often enough) I would like to rewrite it (see CM's answer below),
but at the end...
(acting as "fireman" as I usually do, with critical deadlines and/or costs) I just get into matter so much I need to fix / add / change whatever my job is and then move on to my own projects again, where I actually have quite freedom to do it on my own.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I am not a believer in rewriting things for the sake of it, as each software product has its life cycle which should be followed. I also don't believe in trying to learn everything about a particular language, especially one which is new to you, because if you understand the fundamentals of programming, you should not have problems maintaining that software.
|
|
|
|
|
Over many, many years of watching and participating in software projects I've seen one constant behavioural pattern emerge when a developer is presented with new code.
They want to rewrite it.
It doesn't actually matter if it's in a language they know or don't know. It doesn't matter if the code is well-written or a work of demented monkeys. It also doesn't matter that there's often not the the resources to rewrite it. It often doesn't even matter if the developer in question actually wrote the code themselves in a past life.
Developers want to rewrite stuff. We just do.
I'd love to know whether it's because
- we are arrogant (I don't think so)
- everything we write is so bespoke (it shouldn't be - always generalise, right?)
- coding is complex and it's easier and quicker to rewrite than work out what it's meant to do (but...how can you rewrite if you don't know what it does...)
- code has a shelf life and by the time it's handed off it's obsolete (the job security approach)
- it just feels icky and unnatural work on someone else's code because coding is such a personal style, and the sooner we all agree on The One True Style software development productivity will explode
My deep down honest feeling about what the majority of developers would ultimately choose, regardless of whether they know the language or not, is "rewrite it". Large or small, important or trivial, deadlines or no. We deep down want to rewrite it.
I open the floor to debate.
cheers
Chris Maunder
|
|
|
|
|
We should rewrite your 5 points into a different order. That should make your point more clear 
Hogan
|
|
|
|
|
Some prefer to do this in iterations (kind of evolution from ideas->crude-hack->prototype->usable-version->extensible-version->maintainable-version->...) - all involving of re-writing - mostly own code.
Some people claim that only after rewriting at least twice, the implementation is in a good shape - I don't know if this is true. I observe that the first version is not really in a good shape in average.
I think it also has to do with not focussing on added value and with over-compensation and over-engineering:
- focus: if you do a ceratin project for the first time, you play with a lot of ideas and barely manage to focus on the real thing (that's where e.g. SCRUM or alike may help to focus on added value and not engineering playground)
- over-compensation: if you do a second generation of some product, you have too many weeknesses of the former generation in mind and "forget" about the many well behaving features. So, the weeknesses of the former generation must "go away" now. This leads to an architecture, design, and implementation that covers many special cases and barely manages the common cases well enough.
- over-engineering: some developpers tend to over-engineer in the sense "this could also be useful and that is cool too, so let's (silently) prepare for this and that too". If not properly steered into the "added value" direction and "lean developemnt" (only do what's requested, and in a decend way) then the implementation gets cluttered with hooks for this and that and whatever else might be potentially useful some time...
Finally it's a matter of getting these forces under control and focus on "lean development" and "added value". The task: "herd the cats" 
PS: as a team lead/manager/product owner (you name it), you have to justify the effort/cost/quality. So the question to rewrite or not (refactor) is to be evaluated. Not on the tiny detail but on the larger scale - where it matters. Why? Cost/gain? Risk/can we test? Do we (finally) know what it is exepcted to do? etc.
|
|
|
|
|
I mad an art of "not to code too early". It is hard, but I try to make some paperwork with use cases, MVC and GUI design and discuss it.
It is interesting too see, that this "wasted" time is well spend. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I used to rewrite everything I could. I also used to think that code only gets worse (read: uglier, more complex, less maintainable) over time as bugs were fixed and enhancements added.
But after many years of coding I slowly got better at refactoring and more conscientious when fixing bugs, so that now I really do believe that when I make changes to code I make the code "better" (not just less buggy).
I think any code can be refactored. However if the code has become very large, tightly coupled and complex then it sometimes makes sense to just rewrite it (although it would have to be very bad!). Normally small bits of exceptionally bad code can just be hacked out and rewritten without rewriting everything though.
By the way, I had one guy working for me that had a habit of fixing null reference exceptions by adding a check for null before the failing code. It took a long time to convince him that he should be looking for why the reference was null! I apologise if he is reading this - I won't mention any names! But that is an example of how the quickest fix is almost never the best fix.
|
|
|
|
|
I think I may be in the minority.
I feel the urge to rewrite code only if I find it incomprehensible or unduly complex. Otherwise, I (much) prefer to treat someone else's code as a black box and just assume it works. If it doesn't, it's their responsibility to fix it. If it becomes my responsibility, then I have no qualms about modifying/rewriting it. However, I try to keep my changes to a minimum.
/ravi
|
|
|
|
|
You have ascended.
cheers
Chris Maunder
|
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
