By the time technical debt becomes evident enough for it to be noticed as a problem, it is most often too late to do anything about it. For those that don't believe me, show me enough businesses that have successfully refactored their way out of meaningful technical debts. The majority of case studies I know of prove me right on this point.
Usually when someone argues to refactor a system, one of two things happen. The developer loses the argument and is left frustrated. Or the developer wins the fight but finds that the cost is too high to successfully dig out of the hole.
When you're building a house, you've got to keep its structure sound as you go. If you violate architectural principles along the way, you will find it prohibitively costly (impossible) to revise your prior choices.
As long as we think bad architectural decisions are justifiable -- a mentality enforced by the idea that sound architecture comes at the cost of delivery time -- then we will forever be flailing.
The fundamental problem is that industry has failed to deliver good architects. The hacker culture and desperation of industry for coders has produced an ignorance, disinterest, and almost philistine disdain for the architectural skillsets. (Note: by architectural skillsets, I mean the ability to keep your technical components cohesive and decoupled with minimal interfaces.)
A skilled architect knows that solid design is a function of skill not of time. A skilled architect knows that there's no tradeoff between time and sound design. The comprimises in the face of time pressure are not to be made on the architecture. The concessions to be made are on how generalized you'll make a technical component or which features are most important to deliver today (think Minimimum Viable Product, a notion consistent with good architecture not opposed to it.)
But a majority of practitioners in our profession never learn the architectural skillsets and how to apply them. We learn how to hack, to code, to deliver -- this is all good -- but we don't learn how to build sound architectures.
Acadmeic environments have trouble teaching it because its a skillset acquired through years of practice in the real world. Industry has trouble teaching it because businesses can't afford to send their juniors off to go learn it. They need the juniors to execute, not go through the hard labor of learning architectural skills.
Our industry needs to figure out a way to produce workers with the right skillsets. Then we can avoid the major technical debts in the first place, without thinking we have to make a tradeoff on time. It is too prohibitive to dig yourself out of an unsound architecture. You have to build the house right. That it is "soft"ware doesn't change the game. The house analogy applies.
We have to produce good architectures to begin with. There's no other way. And that requires skill in architecture, a skill far far too but unnecissarily rare in this industry.
Good architecture is a windmill. To do that right, you have to know how your requirements will change and grow over time, and put effort into being flexible and extensible in those feature areas.
But seeing into the future is risky/imperfect. So code bases are full of clever features and libriaries that are used exactly once. And where rapid growth happened but the code wasn't prepared, sketchy chains of conditions and runon code to paper over the gaps.
I have to disagree. It doesn't take prescience to build solid architectures. It takes skills.
Prescience (understanding your future requirements) can help dictate what your priorities are as a business, what features and flexibility to deliver today, but it has little to do with architectural soundness, which is simply a property of a system (independent of and not relative to the future).
This is my point -- to argue that a architectural sound choice is too expensive today is right only if the right skills aren't present. This is a problem for our industry to solve.
There are so many decisions to make, and they depend upon knowing where you're going. The 'soundness' of the system is a cool property, but it doesn't help make your code nimbler unless the right flexibility is in place. What other purpose is there to architecture?
Architectural flexibility and architectural soundness are orthogonal properties. An inflexible system that is architecturally sound may obligate you to build more than its more flexible counterpart when novel use cases come around but it allows you to build more when these use cases come. An architecturally unsound system makes it prohibitively expensive to solve future use cases.
So the purpose of architecture, I'd say, is to first ensure soundness (which should cost no more than building an unsound system so long as you have the right skill set) and only then strike the right level of flexibility in the architecture (another, separate skill set that is valuable but less of a current industry problem, imo).
You can evolve the flexibility of a sound architecture but you can't do much with an unsound one. Inflexiblity in a system is generally a tractable "problem". Unsoundness is not (unwinding coupling, eg, is rarely tractable.)
Usually when someone argues to refactor a system, one of two things happen. The developer loses the argument and is left frustrated. Or the developer wins the fight but finds that the cost is too high to successfully dig out of the hole.
When you're building a house, you've got to keep its structure sound as you go. If you violate architectural principles along the way, you will find it prohibitively costly (impossible) to revise your prior choices.
As long as we think bad architectural decisions are justifiable -- a mentality enforced by the idea that sound architecture comes at the cost of delivery time -- then we will forever be flailing.
The fundamental problem is that industry has failed to deliver good architects. The hacker culture and desperation of industry for coders has produced an ignorance, disinterest, and almost philistine disdain for the architectural skillsets. (Note: by architectural skillsets, I mean the ability to keep your technical components cohesive and decoupled with minimal interfaces.)
A skilled architect knows that solid design is a function of skill not of time. A skilled architect knows that there's no tradeoff between time and sound design. The comprimises in the face of time pressure are not to be made on the architecture. The concessions to be made are on how generalized you'll make a technical component or which features are most important to deliver today (think Minimimum Viable Product, a notion consistent with good architecture not opposed to it.)
But a majority of practitioners in our profession never learn the architectural skillsets and how to apply them. We learn how to hack, to code, to deliver -- this is all good -- but we don't learn how to build sound architectures.
Acadmeic environments have trouble teaching it because its a skillset acquired through years of practice in the real world. Industry has trouble teaching it because businesses can't afford to send their juniors off to go learn it. They need the juniors to execute, not go through the hard labor of learning architectural skills.
Our industry needs to figure out a way to produce workers with the right skillsets. Then we can avoid the major technical debts in the first place, without thinking we have to make a tradeoff on time. It is too prohibitive to dig yourself out of an unsound architecture. You have to build the house right. That it is "soft"ware doesn't change the game. The house analogy applies.
We have to produce good architectures to begin with. There's no other way. And that requires skill in architecture, a skill far far too but unnecissarily rare in this industry.