6 ms·

I'm constantly fighting the sunk cost fallacy with managers, I'm surprised it hasn't been mentioned, or maybe it has been but in a different form?

mgkimsal 7y ago
"Individuals commit the sunk cost fallacy when they continue a behavior or endeavor as a result of previously invested resources (time, money or effort)" WRT software projects, what's the opposite? When I bring up sunk cost, the assumption is that I'm lobbying for wholesale rewrite. In some (not all) cases I am - take the lessons learned, maybe some algorithms, data, whatever, and rebuild. The standard rejoinder to that is "what makes you think you're so much smarter/better than the previous team?" Well... sometimes I maybe am. Or... the strength of the current team is just... more demonstrable? Or... there's no one left from the previous team that even understands the previous system, so ever day spent is often wasted in just trying to learn what they did, only to find out... hey - they really just had no clue what they were doing. We've all seen this (and, early on, I likely was in the position of the offending party a few times). But sunk cost fallacy is a real thing. How do you combat it?
- akvadrako 7y ago
  Wholesale rewrites often have huge future costs, so I don’t think dismissing them is a sunk cost fallacy.
  - mgkimsal 7y ago
    That's not what I was suggesting. I was suggesting that dismissing any calls for any change (whether it's whole rebuild or any degree of aggressive change) is often justified with "but we've already paid $x for this project". Couple that with then also complaining about further costs just grinds my gears. Probably 1/3rd of the projects I've worked on over the last 20 years were software systems that were objectively/measurable poor, and probably half of those warranted a rebuild, and genuinely not 'flavor of the month' justifications. You can't cheaply and safely, for example, run a business on foxpro/db2, relying on one person in a different country with all the source code, running in a virtualized windows XP environment on Windows server 2000, while also wanting to modify your business processes and grow your business. I'm not saying it can't be done, but the costs and risks outweight whatever benefit you've already bought and paid for the last 20 years.
- lazyasciiart 7y ago
  You clearly lay out the future costs of both options in a way that demonstrates you aren't just unaware of how much work will go into the change. That said, rewriting a system you don't understand is pretty hard to do successfully.
  - mgkimsal 7y ago
    the problems aren't usually technical as much as political or 'business' generally (though sometimes technical stuff presents challenges, certainly). There's almost always an assumption, I've found, when coming in to existing projects, that they "really" work a certain way and maybe there's just "a bug here" or "some small fix needed over there". Sometimes that's the case, but more often than not, even after those things are 'fixed', nothing actually does what the people in charge thought it was doing. They've sometimes fundamentally misunderstood what they'd required/specced out with a previous team, or, in some cases, the previous team really didn't know how much they didn't know, or in a couple case, they were simply lying for months on end, cashed checks, then left. "rewriting a system you don't understand is pretty hard" getting a team to successfully spec out what they need is pretty hard, imo, regardless of whether it's greenfield, rebuild, or clarifying expected behaviour in a current system. The big challenge I've come across with "incremental changes to existing systems" happens when it really doesn't do (and never did) what people thought was happening. "No, this isn't calculating daily compound interest - it's calculating monthly." "No, the reports aren't able to be regenerated from previous points in time because historical information was never stored anywhere - you simply now don't have 4 years of data you thought you had - the previous reports you were told were being regenerated were just being pulled from a cache." Fixing problems like above may mean battling through lots of bad code and many many contentious discovery/planning/testing meetings, and... the result is now someone has a 'functioning' system running on codeigniter 2 with hard dependencies on php 5.2. Years ago I faced a situation with a Rails app which "just needed a few modules finished and a few tweaks". It was done in Rails 1 and had insane amounts of runtime monkey patching. 3 different Rails shops I went to indicated it was not worth the time/effort to try to 'upgrade' what was there. They'd rebuild greenfield and salvage what bits they could from the previous project. Many of my experiences have been with smaller organizations (less than 50 people - sometimes less than 10), and there's rarely a full team of competent IT people who can review/vet/verify. "Never rebuild from scratch" - it's not bad advice, but it has a lot of assumptions that aren't always true.
- sosborn 7y ago
  > But sunk cost fallacy is a real thing. The fallacy is a real thing, but that doesn't mean that it is always applicable. Decisions are based on many factors and most of the time, "We've invested a lot of money into this" isn't the only one on the table, even if it is the only one they are saying out loud.
- vharuck 7y ago
  >"what makes you think you're so much smarter/better than the previous team?" You hopefully learned from the problems they encountered, which they likely didn't know about when they started.

mgkimsal 7y ago

"Individuals commit the sunk cost fallacy when they continue a behavior or endeavor as a result of previously invested resources (time, money or effort)" WRT software projects, what's the opposite? When I bring up sunk cost, the assumption is that I'm lobbying for wholesale rewrite. In some (not all) cases I am - take the lessons learned, maybe some algorithms, data, whatever, and rebuild. The standard rejoinder to that is "what makes you think you're so much smarter/better than the previous team?" Well... sometimes I maybe am. Or... the strength of the current team is just... more demonstrable? Or... there's no one left from the previous team that even understands the previous system, so ever day spent is often wasted in just trying to learn what they did, only to find out... hey - they really just had no clue what they were doing. We've all seen this (and, early on, I likely was in the position of the offending party a few times). But sunk cost fallacy is a real thing. How do you combat it?

akvadrako 7y ago
Wholesale rewrites often have huge future costs, so I don’t think dismissing them is a sunk cost fallacy.
- mgkimsal 7y ago
  That's not what I was suggesting. I was suggesting that dismissing any calls for any change (whether it's whole rebuild or any degree of aggressive change) is often justified with "but we've already paid $x for this project". Couple that with then also complaining about further costs just grinds my gears. Probably 1/3rd of the projects I've worked on over the last 20 years were software systems that were objectively/measurable poor, and probably half of those warranted a rebuild, and genuinely not 'flavor of the month' justifications. You can't cheaply and safely, for example, run a business on foxpro/db2, relying on one person in a different country with all the source code, running in a virtualized windows XP environment on Windows server 2000, while also wanting to modify your business processes and grow your business. I'm not saying it can't be done, but the costs and risks outweight whatever benefit you've already bought and paid for the last 20 years.
lazyasciiart 7y ago
You clearly lay out the future costs of both options in a way that demonstrates you aren't just unaware of how much work will go into the change. That said, rewriting a system you don't understand is pretty hard to do successfully.
- mgkimsal 7y ago
  the problems aren't usually technical as much as political or 'business' generally (though sometimes technical stuff presents challenges, certainly). There's almost always an assumption, I've found, when coming in to existing projects, that they "really" work a certain way and maybe there's just "a bug here" or "some small fix needed over there". Sometimes that's the case, but more often than not, even after those things are 'fixed', nothing actually does what the people in charge thought it was doing. They've sometimes fundamentally misunderstood what they'd required/specced out with a previous team, or, in some cases, the previous team really didn't know how much they didn't know, or in a couple case, they were simply lying for months on end, cashed checks, then left. "rewriting a system you don't understand is pretty hard" getting a team to successfully spec out what they need is pretty hard, imo, regardless of whether it's greenfield, rebuild, or clarifying expected behaviour in a current system. The big challenge I've come across with "incremental changes to existing systems" happens when it really doesn't do (and never did) what people thought was happening. "No, this isn't calculating daily compound interest - it's calculating monthly." "No, the reports aren't able to be regenerated from previous points in time because historical information was never stored anywhere - you simply now don't have 4 years of data you thought you had - the previous reports you were told were being regenerated were just being pulled from a cache." Fixing problems like above may mean battling through lots of bad code and many many contentious discovery/planning/testing meetings, and... the result is now someone has a 'functioning' system running on codeigniter 2 with hard dependencies on php 5.2. Years ago I faced a situation with a Rails app which "just needed a few modules finished and a few tweaks". It was done in Rails 1 and had insane amounts of runtime monkey patching. 3 different Rails shops I went to indicated it was not worth the time/effort to try to 'upgrade' what was there. They'd rebuild greenfield and salvage what bits they could from the previous project. Many of my experiences have been with smaller organizations (less than 50 people - sometimes less than 10), and there's rarely a full team of competent IT people who can review/vet/verify. "Never rebuild from scratch" - it's not bad advice, but it has a lot of assumptions that aren't always true.
sosborn 7y ago
> But sunk cost fallacy is a real thing. The fallacy is a real thing, but that doesn't mean that it is always applicable. Decisions are based on many factors and most of the time, "We've invested a lot of money into this" isn't the only one on the table, even if it is the only one they are saying out loud.
vharuck 7y ago
>"what makes you think you're so much smarter/better than the previous team?" You hopefully learned from the problems they encountered, which they likely didn't know about when they started.