|
It really depends on a lot of factors.
- How much time do you have?
- What was the original language, and is in common use today?
- Was the original language the right choice for the function provided?
- Is this just a one-off, or will it need to be used often and maintained?
- Will it always need to run the same platform?
Those are just a few.
I currently have a similar issue. I may need to work on a tool that is unfunded, undocumented, has no requirements, and is broken. Oh, by the way, it is written in Clarion, a 4th gen language that may be interesting to learn, but may never cross my path again in my lifetime. Do I learn just enough to rewrite it in another language or script? Do I become proficient in it and become a Clarion guru? What if it turns out to be a really useful, but no one wants to use it anywhere? I look forward to figuring all this out.
|
|
|
|
|
Any (programming) language is easy to read, so understanding the basic idea of the program (in totally unknown language) is something to do in several minutes. Rewriting it shouldn't take that long. But if the language appears once, it is possible to appear again. So read the language inside out (in my free time).
|
|
|
|
|
I dunno about that, I have PERL5 code I wrote myself that I'd have to really think about.
Then again, RegExs have always been a write-only technology for me.
|
|
|
|
|
PERL is ok but programmers who like to show off that they can do everything in one line drive me nuts!!!
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
Being forced to learn a new language is the only way i bother to switch from what i am comfortable in, so it if is expected of me, then i'm all in.
I prefer doing things to the best of my ability, so knowing just enough is not good enough.
|
|
|
|
|
Of course, most things depend on context.
Is this mission-critical code? What stage in the project lifecycle are we at? Is the purpose of the code well documented? Is the mechanism well understood? Is there someone else in the organization who knows the language well and can evaluate my changes if I make them? What is the fall-back if my changes have to be undone right before (or right after) ship? Is the language it's in one that the team generally uses or is this some outlier? Do we have an established test plan and committed QA resources for this code I can use to validate my changes? Etc.
Rewriting incurs a large risk in the short term. Making changes in a language I don't know well enough incurs a risk that's hard to measure and ameliorate. Code that goes out to the field can be harder to repair than something run on our servers or run as an internal tool.
Like most project decisions, it comes down to risk assessment and risk management.
But all other things being equal, I'd probably do what I needed to change it in the language as-is, unless I had time and luxury to rewrite it. Unless it looked like fun to rewrite. Then I'd totally do that
|
|
|
|
|
Agreed, my answer would change based on the level of the effort, future development of the project regard less of language, and appropriateness of the language to the task.
|
|
|
|
|
but then continue to learn more "extra" things about the language as I maintain it (as time permits).
|
|
|
|
|
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
|
|
|
|
|
Maybe we in general do code too early, and leave it as is, instead of design and only then code (let's assume that the average developer has *not* the attitude of "not-invented-here").
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
|
|
|
|