8 ms·

I have seen half a dozen otherwise useful projects retired or criticized because "the original developers are all gone and no one understands it any more." The

I have seen half a dozen otherwise useful projects retired or criticized because "the original developers are all gone and no one understands it any more." The code worked, and continued to work, and didn't need really active development, so the org decided the project's programmers should move on to something new, or that the knowledge they have isn't especially valuable, and the programmers aren't worth keeping happy. And a couple of years later, no one knows how to update the code for a changing outside environment, updated input styles or whatever. And all that investment is gone.

ramesh31 4y ago
It's not "gone", it served its purpose. Software is born, lives, and dies. By the time a project is 3-4 years old, unless it is a core central service, the business (if it is competing successfully) has most likely moved far beyond the initial assumptions laid out at its' creation.
- compiler-guy 4y ago
  Don't know what kind of projects you are working on, but in the world where I work, source-code that is literally decades old is common, and companies pay extremely good money for people who understand it. This includes things like airline reservation systems, scientific computing models, compilers for obscure dsls, and the like.
- tyre 4y ago
  If a business is competing successfully I don’t think you’re going to see software obviated every three years. Software isn’t like living beings that up and die. They evolve over time. Companies doing rewrites every three years have a hard ceiling.
- marcosdumay 4y ago
  > it served its purpose That's a blind jump. We don't know the purpose, we don't know how much was invested, how much was already recovered, and how much more could be earned if the program was allowed to live. All we know is that it has recently hit fitness to purpose, and that the fitness caused it to be abandoned.
- guntherhermann 4y ago
  It sounds like you haven't been in the situation the parent is describing. I have and still am. We have stuck one ancient piece of software in a docker container and have our fingers crossed that it continues to work. This software is OLD, early Perl 5 old. Nobody in the department understands Perl or wants to. The business (read: product owner) has deemed it unimportant to update or understand, but I assure you that if it stopped working, it would affect millions of tax payers, upper management would find out (read: VP, CEO), and heads would roll. Everything is fine, until it isn't. Your thinking from the perspective of a startup might be true, but from the perspective of a company that is many decades old and has a dozen layers of management... perhaps not so much
  - ramesh31 4y ago
    >It sounds like you haven't been in the situation the parent is describing. Sure I have. And the first few times I too thought that it mattered. But it doesn't. None of the stuff we care about as software developers actually matters. We are just pawns for the people making money decisions. Completely replaceable automatons. If what you are doing is not directly supporting a strategic business goal, you are doing nothing but costing a business money. And cost centers are the first to be cut. You can sit there with your sense of self importance, thinking that the cleanliness and elegance of your code matters. But it just doesn't. Nobody cares. And the sooner you let go of thinking it matters the sooner you can focus your effort on what does. The reality is that when whatever old house of cards you're running fails for whatever reason, the business will switch to a vendor that covers 95% of the use case, while being much cheaper and not requiring FTE support. It will be a tiny bump in the road for the business, replacing this thing that you thought was a world beating make or break technology.
  - Micoloth 4y ago
    That's amazing! Can you share more about what sector you are working in and what the software in question does?
  - WesolyKubeczek 4y ago
    The problem that your product owner cannot see any value in replacing/understanding/modernizing that piece of software, but should it fail, the heads would roll, speaks of a bigger problem in your organization than an ancient piece of software. You have been able to put it in a container and it’s running, so unless the kernel itself changes drastically so old libc will just stop working, it’s going to be able to work unchanged for a decade more. But the communications problem between management layers is way bigger than that, and could probably bite in some other situation.
- alex-nt 4y ago
  Fun story about the 3-4Y window, one of the execs at my company was having a Q&A, and he gave an example in another question a new set of components, saying that he expects them to be in use for the next 20Y. I asked why does he think he can keep the know-how and outsmart the competition (components were part of algo trading and other trading related things) for the next 20y with just this investment, and he just downplayed my question as an IT guy wanting more money/work. ¯\_(ツ)_/¯
- giaour 4y ago
  3-4 years is very short as far as software lifespans go. Software libraries that are 10-15 years old are commonplace in both open source and at FAANGs, and some industries practice "extreme longevity": any domain where you wouldn't be surprised to run into a mainframe is probably also running code with a 30 year+ lineage.
  - andrewf 4y ago
    I don't think it's a coincidence that software lifetime has converged to the time it takes an initial stock grant to vest.
doix 4y ago
But someone can figure it out. It doesn't matter that nobody knows anymore, if there's a real need with no alternative, someone can figure it out. I used to work for a company that had an internal tool. It wasn't used anymore, everyone that worked on it was long gone, the source code was "lost". There was some emergency and someone needed to use the tool to look at some old data. Lots of panic and people claiming it was impossible. I opened up the executable in ollydbg, patched the executable so it worked properly, and life went on. I'm sure the source code wasn't lost, it would have been on a tape backup that people were too lazy to try and recover. If the source code is available then it's even significantly easier. I don't buy this whole "nobody knows how to update the code" reasoning. If the code can't be updated, it's a matter of incentives and prioritization.
- pasquinelli 4y ago
  what was the update? the kind of update that "programming as theory building" is talking about is like, the next version of a piece of software.
  - doix 4y ago
    Yes, but the comment I replied to implied that software will just stop working. If software has been working for years and then stops working, it's usually something fairly small than can be hacked quickly. In my specific case, the tool had a whole bunch of hardcoded values. It checked authorization against an LDAP server, that all changed. Connected to a sql sever that moved + credentials changed. Assumed certain files existed on certain network drives which were moved. Technically, it could have been solved by faking all the infrastructure. It also could have been solved by digging out the source code from tape drives. But everyone was running around saying it was "impossible". I was shocked how quickly people tossed out "impossible". It could have been done with a simple hex editor, but the new values were longer than the old values, so the strings didn't fit. I put the new strings at the end of the .data section and then just changed a bunch of offsets. I agree that if you're writing the next version of the software, you can't do that quickly when nobody knows how the current version works. But chances are, you're not writing the next version of the software quickly even without churn.
majormajor 4y ago
I've seen the first part of this story a lot. Software product is delivering value, maintenance isn't needed much, people move on to other projects[0], people forget about it, then a couple of years later a change is needed. But how would the first response in that "couple of years later" scenario be "throw away all that investment and start from scratch" instead of "dig into how it works"? That's not a long time, really. [0] this is a good thing, IMO. If every project needs constant maintenance from its "owner" you as a company are going to rapidly run out of resources to do new things. (There's a closely related thing, here, though, that as an individual or a low-to-medium level manager, keeping track of these risks and low-level maintenance areas is part of your job to find ways to keep it from ever turning into a disaster. At some point - 10 years, 15, 20... maybe the knowledge gap gets way too big for the current team - then get proactive.)
- commandlinefan 4y ago
  > But how would the first response be "throw away all that investment and start from scratch" instead of "dig into how it works"? Because start from scratch is more predictable ("estimable") than "dig into how it works". "Dig into how it works" is better in the long run, but will take longer. All software management is laser focused on speed and predictability rather than long-term quality.
  - majormajor 4y ago
    This is exactly the case where I think starting from scratch is the most difficult to estimate. This thing we need to update is a mystery-box, right? You don't know the code. You don't know all its edge cases. Tons of potential bugs could be introduced (or re-introduced) if you change it in the wrong way. Replace-from-scratch has all the same risk of getting things wrong because of that lack of knowledge and a bunch more new-code-writing on top of it. Estimating new development often fails; estimating it in the face of business requirement uncertainty is even worse.
    - WorldMaker 4y ago
      Can you quantify that to the management in that case? To certain styles of management focused on "always building new products" to guarantee their worth/value, they absolutely will get blinders on and believe "new products are easy and more predictable than maintenance of old products". Those blinders are hard to take off once they get into that sort of pattern. All of their processes are built around "new products". That starts to be the hammer that wants to dismantle old products because they don't do maintenance (that's someone else's problem) but they surely know how to build new products. They are the build new products group, that's what believe they do. Building new products is exciting and they can be passionate about it. I also think that's generally the wrong way to work and does plenty of harm and creates a lot of unnecessary stress on development teams caught in those cycles. But I've certainly seen plenty of management teams that do work that way in the real world and maybe don't question it enough.
dec0dedab0de 4y ago
Sometimes it's worse when they start tacking on changes in an inconsistent way. It's always painfully obvious when a company is shipping a product that has been acquired multiple times, and/or hacked on by contractors that don't care about the past or future of the project. I'm looking at you Aruba, Cisco, and pretty much every network vendor.
scioto 4y ago
I'd like to disagree with you there, because of this one data point ;-). I worked on an application where I knew just enough to make spot changes, while the other developer who had made the most core changes continued on with the core. Then he left. So as more core changes needed to be made, none OMG due to Production issues, that made me dip into more and more of the legacy code, and I grokked what was going on. I wasn't happy with it, but I understood it enough to know that to make it truly maintainable would require a total re-do. But the code that was there worked, and as time went on I even took other developers' bolt-on additions and made their functionality take advantage of the sub-optimal idioms the core used, so that at least if someone else had to make changes, they'd only have to deal with one pattern. I've made wiki pages to describe it, but still any other developer who works on it ends up asking question after question and complaining why the documentation isn't in the wiki (it is; they just don't want to look). We eventually moved to another servlet container, and I filled in the missing functionality the new server lacked, still keeping the original core code. I've done that with two other applications at our company as well. Why haven't I moved on? Hey, I'm older now, and it's an 8 to 5 job you can't easily find any more.

ramesh31 4y ago

It's not "gone", it served its purpose. Software is born, lives, and dies. By the time a project is 3-4 years old, unless it is a core central service, the business (if it is competing successfully) has most likely moved far beyond the initial assumptions laid out at its' creation.

compiler-guy 4y ago
Don't know what kind of projects you are working on, but in the world where I work, source-code that is literally decades old is common, and companies pay extremely good money for people who understand it. This includes things like airline reservation systems, scientific computing models, compilers for obscure dsls, and the like.
tyre 4y ago
If a business is competing successfully I don’t think you’re going to see software obviated every three years. Software isn’t like living beings that up and die. They evolve over time. Companies doing rewrites every three years have a hard ceiling.
marcosdumay 4y ago
> it served its purpose That's a blind jump. We don't know the purpose, we don't know how much was invested, how much was already recovered, and how much more could be earned if the program was allowed to live. All we know is that it has recently hit fitness to purpose, and that the fitness caused it to be abandoned.
guntherhermann 4y ago
It sounds like you haven't been in the situation the parent is describing. I have and still am. We have stuck one ancient piece of software in a docker container and have our fingers crossed that it continues to work. This software is OLD, early Perl 5 old. Nobody in the department understands Perl or wants to. The business (read: product owner) has deemed it unimportant to update or understand, but I assure you that if it stopped working, it would affect millions of tax payers, upper management would find out (read: VP, CEO), and heads would roll. Everything is fine, until it isn't. Your thinking from the perspective of a startup might be true, but from the perspective of a company that is many decades old and has a dozen layers of management... perhaps not so much
- ramesh31 4y ago
  >It sounds like you haven't been in the situation the parent is describing. Sure I have. And the first few times I too thought that it mattered. But it doesn't. None of the stuff we care about as software developers actually matters. We are just pawns for the people making money decisions. Completely replaceable automatons. If what you are doing is not directly supporting a strategic business goal, you are doing nothing but costing a business money. And cost centers are the first to be cut. You can sit there with your sense of self importance, thinking that the cleanliness and elegance of your code matters. But it just doesn't. Nobody cares. And the sooner you let go of thinking it matters the sooner you can focus your effort on what does. The reality is that when whatever old house of cards you're running fails for whatever reason, the business will switch to a vendor that covers 95% of the use case, while being much cheaper and not requiring FTE support. It will be a tiny bump in the road for the business, replacing this thing that you thought was a world beating make or break technology.
- Micoloth 4y ago
  That's amazing! Can you share more about what sector you are working in and what the software in question does?
- WesolyKubeczek 4y ago
  The problem that your product owner cannot see any value in replacing/understanding/modernizing that piece of software, but should it fail, the heads would roll, speaks of a bigger problem in your organization than an ancient piece of software. You have been able to put it in a container and it’s running, so unless the kernel itself changes drastically so old libc will just stop working, it’s going to be able to work unchanged for a decade more. But the communications problem between management layers is way bigger than that, and could probably bite in some other situation.
alex-nt 4y ago
Fun story about the 3-4Y window, one of the execs at my company was having a Q&A, and he gave an example in another question a new set of components, saying that he expects them to be in use for the next 20Y. I asked why does he think he can keep the know-how and outsmart the competition (components were part of algo trading and other trading related things) for the next 20y with just this investment, and he just downplayed my question as an IT guy wanting more money/work. ¯\_(ツ)_/¯
giaour 4y ago
3-4 years is very short as far as software lifespans go. Software libraries that are 10-15 years old are commonplace in both open source and at FAANGs, and some industries practice "extreme longevity": any domain where you wouldn't be surprised to run into a mainframe is probably also running code with a 30 year+ lineage.
- andrewf 4y ago
  I don't think it's a coincidence that software lifetime has converged to the time it takes an initial stock grant to vest.

doix 4y ago

But someone can figure it out. It doesn't matter that nobody knows anymore, if there's a real need with no alternative, someone can figure it out. I used to work for a company that had an internal tool. It wasn't used anymore, everyone that worked on it was long gone, the source code was "lost". There was some emergency and someone needed to use the tool to look at some old data. Lots of panic and people claiming it was impossible. I opened up the executable in ollydbg, patched the executable so it worked properly, and life went on. I'm sure the source code wasn't lost, it would have been on a tape backup that people were too lazy to try and recover. If the source code is available then it's even significantly easier. I don't buy this whole "nobody knows how to update the code" reasoning. If the code can't be updated, it's a matter of incentives and prioritization.

pasquinelli 4y ago
what was the update? the kind of update that "programming as theory building" is talking about is like, the next version of a piece of software.
- doix 4y ago
  Yes, but the comment I replied to implied that software will just stop working. If software has been working for years and then stops working, it's usually something fairly small than can be hacked quickly. In my specific case, the tool had a whole bunch of hardcoded values. It checked authorization against an LDAP server, that all changed. Connected to a sql sever that moved + credentials changed. Assumed certain files existed on certain network drives which were moved. Technically, it could have been solved by faking all the infrastructure. It also could have been solved by digging out the source code from tape drives. But everyone was running around saying it was "impossible". I was shocked how quickly people tossed out "impossible". It could have been done with a simple hex editor, but the new values were longer than the old values, so the strings didn't fit. I put the new strings at the end of the .data section and then just changed a bunch of offsets. I agree that if you're writing the next version of the software, you can't do that quickly when nobody knows how the current version works. But chances are, you're not writing the next version of the software quickly even without churn.

majormajor 4y ago

I've seen the first part of this story a lot. Software product is delivering value, maintenance isn't needed much, people move on to other projects[0], people forget about it, then a couple of years later a change is needed. But how would the first response in that "couple of years later" scenario be "throw away all that investment and start from scratch" instead of "dig into how it works"? That's not a long time, really. [0] this is a good thing, IMO. If every project needs constant maintenance from its "owner" you as a company are going to rapidly run out of resources to do new things. (There's a closely related thing, here, though, that as an individual or a low-to-medium level manager, keeping track of these risks and low-level maintenance areas is part of your job to find ways to keep it from ever turning into a disaster. At some point - 10 years, 15, 20... maybe the knowledge gap gets way too big for the current team - then get proactive.)

commandlinefan 4y ago
> But how would the first response be "throw away all that investment and start from scratch" instead of "dig into how it works"? Because start from scratch is more predictable ("estimable") than "dig into how it works". "Dig into how it works" is better in the long run, but will take longer. All software management is laser focused on speed and predictability rather than long-term quality.
- majormajor 4y ago
  This is exactly the case where I think starting from scratch is the most difficult to estimate. This thing we need to update is a mystery-box, right? You don't know the code. You don't know all its edge cases. Tons of potential bugs could be introduced (or re-introduced) if you change it in the wrong way. Replace-from-scratch has all the same risk of getting things wrong because of that lack of knowledge and a bunch more new-code-writing on top of it. Estimating new development often fails; estimating it in the face of business requirement uncertainty is even worse.
  - WorldMaker 4y ago
    Can you quantify that to the management in that case? To certain styles of management focused on "always building new products" to guarantee their worth/value, they absolutely will get blinders on and believe "new products are easy and more predictable than maintenance of old products". Those blinders are hard to take off once they get into that sort of pattern. All of their processes are built around "new products". That starts to be the hammer that wants to dismantle old products because they don't do maintenance (that's someone else's problem) but they surely know how to build new products. They are the build new products group, that's what believe they do. Building new products is exciting and they can be passionate about it. I also think that's generally the wrong way to work and does plenty of harm and creates a lot of unnecessary stress on development teams caught in those cycles. But I've certainly seen plenty of management teams that do work that way in the real world and maybe don't question it enough.

dec0dedab0de 4y ago

Sometimes it's worse when they start tacking on changes in an inconsistent way. It's always painfully obvious when a company is shipping a product that has been acquired multiple times, and/or hacked on by contractors that don't care about the past or future of the project. I'm looking at you Aruba, Cisco, and pretty much every network vendor.

scioto 4y ago

I'd like to disagree with you there, because of this one data point ;-). I worked on an application where I knew just enough to make spot changes, while the other developer who had made the most core changes continued on with the core. Then he left. So as more core changes needed to be made, none OMG due to Production issues, that made me dip into more and more of the legacy code, and I grokked what was going on. I wasn't happy with it, but I understood it enough to know that to make it truly maintainable would require a total re-do. But the code that was there worked, and as time went on I even took other developers' bolt-on additions and made their functionality take advantage of the sub-optimal idioms the core used, so that at least if someone else had to make changes, they'd only have to deal with one pattern. I've made wiki pages to describe it, but still any other developer who works on it ends up asking question after question and complaining why the documentation isn't in the wiki (it is; they just don't want to look). We eventually moved to another servlet container, and I filled in the missing functionality the new server lacked, still keeping the original core code. I've done that with two other applications at our company as well. Why haven't I moved on? Hey, I'm older now, and it's an 8 to 5 job you can't easily find any more.