I disagree with software architecture. There's not enough theory and science in organizing code and understanding complexity. Most of what goes on here is just guessing. If you created "good architecture" it only means future requirements happened to fit your design, aka you made a good guess.
Rarely does anyone design anything that is efficient in the present and adaptable to any possible future simply because there's no science and theory on how to design such a thing. There's some rules of thumb but even following these rules of thumbs people end up with technical debt most of the time anyway. It always happens, if a project lives long enough, more and more "design mistakes" made at project inception become evident.
I have personally found tacit programming to be the solution for this but because there's no theory I can't explain to you definitely why tacit programming is the best way to deal with tech debt of the structural nature.
> Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.
That's fair, but shouldn't we strive to make the best possible guesses in the absence of said theory and science?
Rarely does anyone design anything that is efficient in the present and adaptable to any possible future simply because there's no science and theory on how to design such a thing. There's some rules of thumb but even following these rules of thumbs people end up with technical debt most of the time anyway. It always happens, if a project lives long enough, more and more "design mistakes" made at project inception become evident.
I have personally found tacit programming to be the solution for this but because there's no theory I can't explain to you definitely why tacit programming is the best way to deal with tech debt of the structural nature.