How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
I can think of many reasons.... "we were using python to quickly explore the space and rewrote to rust once we figured out the interface and started to focus on speed and safety", or "the original authors wrote this software in smalltalk but we'd rather it be golang because this simplifies deployment"
> You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
As long as the test-cases are there, why would I care what language software is written in?
Yes but can you plan anything properly in advance? How many unknown unknowns aren't being accounted for? Maybe it's best to plan for improper planning. What to do when (not if) critical decisions start falling apart?
You go back to the design. A few critical changes in the requirements, that's expected. A codebase in which the critical parts change often, that's a red flag
This is equivalent to arguing that tech debt signals poor planning
I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front
It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.
I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?
