3 ms·
Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptation It varies from sh
by stcredzero 8y ago
Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptation
It varies from shop to shop, but what I've seen is that code organization has a lot to do with it. Basically, if your code organization/factoring is really bad, then it's more likely that porting becomes untenable. Ironically, these are the projects that can have the longest lifespans, sometimes developing a history of multiple failed attempts to "port" them. (Really, re-implement while incurring huge opportunity costs.)
> If all of the environmental variables remain the same
Would you like a pony too?
You're seriously missing the point. My point is that the environmental variables never remain the same. (I was making two points, and I think you missed where I switched.)
> 2) you have a reliable syntax driven code rewrite tool
Would you like a pony too?
I repeat. I've been paid good money to use such a tool. I've used such a tool to enable the 1-step-removed porting of a project to a different language variant. Instead of doing the port myself, I was refining a tool which automated the port and enabled the maintainers to easily port all the changed code they were checking in. This lets you do a port without incurring the opportunity cost. I know of a consulting company that once made most of their income with this.
Yes, you can automate away the easy cases, but that's not even half the battle.
You can't simply hit a switch with this, of course. Someone has to put real thought into how the translations are made, especially if you want idiomatic, readable code going out the other end. The good thing about consistent idioms, is that they can be leveraged to multiply that work. The manual part can be re-leveraged through automation.
That's why people hire maintenance programmers like you.
That could be read in a way that sounds less than friendly and maybe a bit elitist.
- notacoward 8y ago> what I've seen is that code organization has a lot to do with it I suggest that your sample is non-representative. Companies don't hire specialists to refactor code that they're abandoning. Dead companies don't hire anyone at all. You don't work on rotten code because nobody does, but that doesn't mean it's not out there. > That could be read in a way that sounds less than friendly and maybe a bit elitist. It could, but that would be on the reader. I didn't say anything to denigrate maintenance programmers.
- stcredzero 8y agoCompanies don't hire specialists to refactor code that they're abandoning. Companies do hire specialists to port code that they're not abandoning. Dead companies don't hire anyone at all. "Zombie" companies can still have big revenues and they can and do pay consultants to do things like port old applications. Again, there have been entire companies based on such activity. I've made money from such companies. You don't work on rotten code because nobody does I was a consultant for a language vendor for 5 years, then continued working in that niche for another 5. My sample size in this context is in the many dozens at least. There's a lot of code I'd call "rotten" out there that people still work on. I didn't say anything to denigrate maintenance programmers. Good. I'm sure I've met a number of them who are probably better coders then either of us when they're half asleep.
- stcredzero 8y agoArrgh. Than!