this is interesting. in my experience it is always the third situation. they try to migrate the data slowly from "old system" to "nexgen". it never works. it sounds like maybe the answer is do a big bang switch over to the new system or don't rewrite at all. (i.e. the system you are rewriting probably needs to be small enough)
Ship of Theseus is the other way. Fact is a lot of companies have code that has been rewritten and they don’t know it, because the devs that did it know they would have been stopped if people knew. But piece by piece, bit by bit, everything was shifted to a new organizational paradigm from the original.
You can’t really do objective case studies on development processes that involve subterfuge. Even if they work.
couple of points. building software is so far from building a house that's not really worth comparing. (just bringing this up because the analogy is used quite a lot). second, the signatories on the agile manifesto may have done some management but most, if not all, were strong developers.
While I think you can write good software with other methodologies I do think agile is a good fit for something that is supposed to change a lot which was the original idea behind software (as opposed to hardware) existing. the core idea is that things will always change, set yourself up so you have early knowledge and can change tack when you need to.
Another thing is depending on your experience you may have been exposed to differing version of agile. I have seen many places where it has been distorted into a KPI / mini deadline / micromanagement framework, which was never the point. From my point of view agile was always about developers teaching managers how they can manage us effectively, given the uncertain nature of software estimation and process of trying ideas and learning new things feeding into working software. it's part of our professional duty to explain how to do these things properly.
> building software is so far from building a house that's not really worth comparing
I disagree. I think the comparison is between engineering part of building a house, i.e. creating blueprints. The actual "blue collar" work in SW engineering is making sure the whole thing compiles, runs and is tested.
> the signatories on the agile manifesto may have done some management but most, if not all, were strong developers
Yeah, that's what I am suggesting with my post, maybe it worked for them, but it was later misinterpreted, or they thought that the secret of their success lies elsewhere.
> is supposed to change a lot which was the original idea behind software (as opposed to hardware) existing
I disagree here. Software is easy to copy first and foremost (you don't need much materials). I think easy to copy does not mean easy to change. For example, DNA sequence is also easy to copy, but difficult to change. (And that's why people wish for rewrites from the ground up.)
> agile was always about developers teaching managers how they can manage us effectively
I disagree. That implies you have a much bigger problem - useless managers. Managers simply have to understand the domain they are managing (and ideally have hands-on experience). There shouldn't be any "teaching" going on.
But I also agree, in a way. I think who needs to listen to SW engineers are product and project managers, that the software is not just a bunch of features to be built, just like a house is not just what you see on the promotional render. That's what my post was about.
I find that many analogies that seem not to hold water actually hold a lot of water, frequently including some the purveyor hoped it wouldn’t.
“Low hanging fruit” is about as stupid an idea if you understand how to make performant systems as it is if you own a mature fruit tree. Going for the low hanging fruit on a real tree grants you the biggest mess. Neither domain works the way idiots pretending to be enlightened think it does. And you can paint a sane picture in both if you know wtf you’re talking about, even a little.
Similarly, what the home improvement industry has taught me is that you can build a house with siding and a roof for about 10% of the cost of the finished house. This house will keep you dry. It will not keep you warm or clothed and feed you. For that you need plumbing, wiring, ceilings, walls, insulation, and finally flooring. These are intensely labor intensive jobs, and if you 1) learn a few of them and 2) know the right people, you can build things to code and pay someone only to sign off on them. Drywalling doesn’t even require that, but it’s a shitload of work.
So yes, in fact you can build an MVP of the house. It’s just the bones and a couple of the most obvious features. And if you live in an old enough house, it’s been refactored and retrofitted so many times that you can’t tell that it used to look a exactly like five other houses within a block radius of your house. And so did all you’re neighbors’.
But they don't care - instead, they just start a new one and repeat the process all over again.
The mistake here - made not just by the devs complaining about tech debt, but also by all of the company's customers - is that the goal is to produce something of value. It's not. It's to produce something promising to be of value at some point in the future, getting as many people as possible, as fast as possible, to buy into that promise (and stringing the paying users, if any, along for as long as possible), and then jettisoning the whole thing once it's past its peak, escaping with riches, to do it all again, or finally go FIRE.
Yep exactly my experience working in a startup. When it was time to make a real product our of the shit spaghetti code they wrote to win customers with """working""" demos, it was too late. Bankruptcy followed.
Isn’t this a slightly different problem? The product built was just vapourware and not really doing the job. So customers went elsewhere when the real version didn’t appear in time? Often companies will win the customers with a genuine working product but complicated code and then hire like crazy and all the new developers struggle and want to rewrite it all. But they mustn’t because it is a working product earning money. So gradual improvement and controlled rewrites of sub areas that need to change the most are focused on to succeed. If a company has gone bankrupt because of spaghetti code of a demo product, it feels to me like the problem was the product being just a demo rather than it being spaghetti code?
You're not wrong! But IMO, the product was being limited to being only a "demo" product because the code was too bad to run extensively in production. I guess it was both problems.
test driven development has been around since the late 90s and was popularised in eXtreme Programming circles, are you sure it's a fad? I find it the most efficient way to write code and keep it running in the long term personally.
