[ByteWelder]

> I must say, I wish for the old days back. Sure, it was slow and laborious, but it resulted in better outcomes and manageability. IMHO, it also resulted in better reliability of software due to the diligence done by several layers.

Those were also the days where it took many years to go from Java 6 to Java 8. Or perhaps to try out Kotlin.

They were the days where legacy code was the norm, and we kept supporting it because nobody dared to change anything for the better. In practice, that's just not something you can maintain in a competitive market, because your competitors _will_ use new technologies and faster/better development processes.

"it just works" might be good enough for maintaining your application, but will it be good enough to find people willing to work in that code base or that environment?

I work for a large business where both the old and new practices are in place (mostly the new ones, though). Focusing on "going fast" is definitely not a good idea, but I believe there's a sweet spot in between.

[reacharavindh]

Sure, mature processes encourage tech stagnation, and discourage even beneficial changes as collateral damage. But, as you say there is line somewhere at which project should move on from "Go fast, ship often, change much and get feature-rich" to "focus on correctness, stable releases, actually maintain our existing features". Perhaps it is really a cycle of both and missing one for the other leads to problems.

[datavirtue]

All code is legacy code. As soon as you start changing the existing code...it is legacy.

I'm on a project now that has not released to prod. It has a lot of new legacy code.