But the person might have the knowledge to build on whatever the system is, without having the mandate to do so. He'd still be the best person to modify the system, but for whatever reason the business doesn't need the edits. Should you keep him happy just in case or let him find another job and take the option to upgrade with him?
I guess if you don't mind the person running an unsupported system then don't. Most businesses desire support, however. You can't control when the old unsupported system is going to fail. You might find yourself doing a forced upgrade to a new system at an inconvenient time with zero time for transition. Strikes me as irresponsible.
Someone has to be able to maintain it. What happens when the one person who understood it leaves and it needs to be modified or upgraded, if they're lucky they can hack it into working and even that's not a good thing as the build has now been modified in a way that is not understood and possibly broken. If they can't figure it out and the need is not that strong they'll leave it as is and just not change whatever they originally had wanted to, ultimately limiting themselves and their solution in someway. The last choice for them is do the only thing they should when there are components that are not understood or can't maintain and rip it out and in the process lose many days or weeks replacing it.
I think there is some value in "someone who has spent billable hours deeply touching the currently running system is still employed at the company." You can have maintenance updates & docs as numerous as you want, but I'd still be terrified of running a production system I don't have trusted nuts-and-bolts expertise in-house for.
Having dealt with a similar setup that basically had to be re-written, I totally agree. I would also like to add that if one senses themselves to be in a situation like this where the system is a messy build-up over years, try to resist adding things that are absolutely not essential. Otherwise, the guy doing the clean-up/re-write down the line may be forced to take not-so-clean approaches to cater to those non-essential bits mainly for backwards compatibility.
True, but at least for personal use you could make that sacrifice of replacing and re-learning stuff as much as possible. Tbh, from an employee's POV I don't even care that much if my company wants to take that risk.
I can only speak of my own experience as a sysadmin, but the more isolated the system is and the less critical it is for operation, the easier it is to delegate the job of doing a software update to coworkers and new hire. Especially if all the issues from doing an update has already been established on several other machines, in which case the update is more or less mechanical in nature.
It reminds me of the story about a thirty year old Commodore Amiga running the AC system for a school district. The district finally decided to modernize the AC for $2 million, but until then it was just cheaper and easier to continue paying a person to run it every year. Replacing hardware systems is expensive and political complicated, while continuing paying an employee is just status quo.
Logically if the OP was never born, his software wouldn't exist, and a company wouldn't have made the judgement that replacing his software asap would be a good use of up to 19 man years of budget
(Of course it's also unknown whether that decision was a sensible one, whether it was forced by external pressure like API changes despite the stability and maintainability of the original system and whether the OP's software possessed equivalent functionality to its expensive replacement. All we know is the choice to create the software again from scratch was, to some extent, influenced by what had already been created)
I am not going to dispute your opinion but rather point out that people are different. Some people don't mind maintaining old systems and some people love being the person who created a new systems D using new technology. Both sets of people are necessary in our field of development and his mother sounds like she is fine with maintenance type of work.
No, he is in need of writing production quality software together with his medium to big sized dev team and he doesn't want to introduce maintenance burden into his project 10 years from now. Software will get improved during it's lifetime and not overwritten from scratch every 2 years.
It depends on the person maintaining it. This one seems complete and up to date, so if he had started at a new company he probably would update it promptly.
> maintenance: still necessary, hire anyone but probably the expensive guys from before
Don't forget: sometimes the copyright is still owned by the contractor that developed it, at which point the options are only "hire the expensive guys from before." Want to make a change and the vendor can't/won't? Oops, guess you're starting over from scratch! Or you don't make the change you wanted to and live with it as-is.
No. The software you sold them should continue to work into the future. I'm saying you shouldn't be afraid to make improvements and leave people behind if they refuse to keep up.
Yeah, I've done this. It's frustrating and easy to burn out doing it because progress seems so arbitrary. Legacy upgrades are usually driven by large problems or the desire to add new features. Getting a grip on the code base while deflecting those desires can be hard.
This type of situation is usually a red flag that the company's management doesn't understand the value of maintaining software until the absolutely have to. That, in itself, is an indicator of what they think of their employees.
One of my older jobs relied on ancient hardware, and the life of the company was measured by parts in the warehouse and vendors who still cared. From their perspective they'd have a modern system as long as your company delivers.
> hey haven't shown any interest in updating the system.
So expensive to update that there's a calculated end-of-life to the system. They'd love to know about your engineer situation. That'd trigger plans put in place a while ago.
Your company could do a last big batch for the city and send the old guy out with a nice bonus.
I know for a fact that my old employer has one client who's still running 4.0, unless they've decided to pay out the ass to upgrade their spaghetti-coded system.
Considering that a) no out-ass money has been offered me, and b) I'm effectively the only person who could even fix bugs in the system, they're still running 4.0.
reply