|
The question lacks context. If it is a small project and does something that the new language is strong at, I do enough to get by. If it was a poor choice of language to begin with, I rewrite it in an appropriate language. If it is a larger project and more complex, I dig in and learn the new language as thoroughly as possible.
|
|
|
|
|
In most of the cases it is enough to learn what's needed. But I have experiences which I got to know the beauty of certain languages when I had to use them accidentally. Isn't it natural that we like to learn something which we know the value of, regardless of how we get to know about it?
|
|
|
|
|
The Art of Maintenance Programming[^]
Basically do the minimum you have to do - that may require you to learn the language inside out - or rewrite the whole thing, but do the minimum.
|
|
|
|
|
On the code and on the language.
The 'need' to rewrite is always strong, but it also depends on the quality of the inherited code.
The aim of learning well a language depends on the attractive the language itsef has. I don't want to know very well COBOL, for instance.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
I had the same thought, but then, if the language has actually some attractive, I would probably have it already learned, no? 
Life was like a box of chocolates; you never know what you're gonna get.
|
|
|
|
|
It does make sense. However, I didn't know how attractive Lua was, before being casually involved with.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
i once inherited a codebase written in VB.NET which I am not too familiar with, I am C# guy largely and not that there are lots of differences apart from the obvious ones. And its also not that i couldn't deal with VB given i have programmed in VB6 as well ages ago so VB.NET is not as different as apples and oranges. Anyway, the codebase was a massive ball of poo laden spaghetti with dead rats inside needless to say, it wasn't easy to work with. It had 39 unique ASP.NET session variables and the entire application was coded in Default.aspx.vb. 
This app was the admin center for one of our other products and was use to import large datasets. It was slow as 4uck and crashed whenever more than 500 records were pushed through. At first I tried to salvage it but very quickly it became apparent that sometimes its just better to rewrite the application properly following a good and robust enough architecture. And so i did and now users process tens of thousands of records every so often without any pain. Feels like a win to me! 
|
|
|
|
|
Yes, sometimes rewriting is not just asserting our talent (well, not only, at least ).
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
But COBOL specialists are sometimes like a unicorn: the rare superstars.
I wouldnt like to pitch into VB6-legacy code, because it is often extremly poor crafted.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
KarstenK wrote: because it is often extremly poor crafted
I think that is more related to low-skilled VB6-Programmers than to VB6-Code
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.
|
|
|
|
|
but the "hen and egg paradoxon" is extremly clear 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
|
KarstenK wrote: extremly poor crafted
Good euphemism! 
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
No thanks 
