3 ms·
> And contrary to many people, I'm fine with the (eternal?) limbo that we then end up with: parts of the codebase using the new stuff, parts still using the old
by quietbritishjim 3y ago
> And contrary to many people, I'm fine with the (eternal?) limbo that we then end up with: parts of the codebase using the new stuff, parts still using the old stuff.
That is fine when, as you described it, there are only two types of code: one still using old technique/technology A and the other using newer version B.
Where it becomes a problem is when you haven't finished the transition and realise you need to start moving on to C, or you leave and the new person doesn't understand the difference (and probably also has their own desired replacement). Before you know it, you have three or even more styles of code in play at once, with diminishing ability to keep moving to the latest version. This is sometimes called the lava layer antipattern [1]
[1] https://mikehadlow.blogspot.com/2014/12/the-lava-layer-anti-pattern.html?m=1 https://mikehadlow.blogspot.com/2014/12/the-lava-layer-anti-...
- deleted 3y ago[deleted]
- berkes 3y agoIt is an antipattern. But IMO still better than "feature freezing" for months, delivering nothing of (business) value for weeks or months, working like madmen trying to remove the last 10% of the old code - which by the 90/10 rule, costs probably 90% of the budget. I'd rather have three or four versions - provided these are marked well, documented, and so on. Even if the codebase uses four versions, at any point in time, there is still only one thats the right one today.