Comment by kmoser
3 hours ago
Some questionable assumptions here:
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better.
> Why does technical debt exist? Because requirements weren't properly clarified before work began.
Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc.
> In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track.
Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
>Because requirements weren't properly clarified before work began
Yea, software is typically way more flexible and fast moving in the real world.
At start of project: "We need software with A, B, and C"
In middle of project: "Our competitor has released with ABCD and E, and if we don't add at least E we might as well cancel the project"
There is also - Our software works 100% fine with what we expected in the field, problem is (new|old) thing showed up and now we have to work around all the bugs in it.
Then there is Chesterton's fence. That 'broken old crap' was actually doing something highly specific that calcified into how the customers systems work. People love ripping crap up and changing stuff, until they figure out it just broke their enterprise clients workflow, and that client pays their salary.