Have you ever been in an old house? Not old, like, on the Historic Register, well-preserved, rich bastard “old house”. Just a house that has been around awhile. A place that has seen a lot of living.
You’ll find light switches that don’t connect to anything; artwork hiding holes in the walls; sometimes walls have been added or removed and the floors no longer match.
Any construction that gets used, must change as needs change. Be it a house or a city or a program, these evolutions of need inevitably introduce complexity and flaws that are large enough to annoy, but small enough to ignore. Over time those issues accumulate until they reach a crisis point. Houses get remodeled or torn down, cities build or remove highways, and programs get refactored or replaced.
You can and should design for change, within reason, because all successful programs will need to change in ways you cannot predict. But the fact that a system eventually becomes complex and flawed is not due to engineering failures - it is inherent in the nature of changing systems.
My 100 year old house has marks on the floor that look like it was worn from a door swinging. Very distinctive arc pattern. Like it was there for many years and was under frequent use.
The problem is that there’s no door there, just a wall, which is also the edge of a dormer…so if there were a door there it would just open out onto a sloping roof.
Every time I register it I contemplate why it’s there and wtf happened.
There was most likely a closet or other crawl space storage area there. My house has closets like that but luckily full height entries to them so we can actually step in. I’ve seen other houses with 1/2 or 1/3 height doors leading to under-roof crawl spaces for storage.
the fact that a system eventually becomes complex and flawed is not due to engineering failures - it is inherent in the nature of changing systems
it is not. It’s just that there will be some point, where you need significant effort to keep the systems structure up to the new demands {1}. I find the debt-metaphor is quite apt [2]: In your scenario the debt accumulates until it’s easier to start fresh. But you can also manage your debt and keep going indefinitily. But in contrast to financial debt, paying of technical debt is much less obvious. First of all it is pretty much impossible to put any kind of exact number on it. On the other hand, it’s very hard to tell what you actually should do to pay it off. (tangent: This is why experienced engineers are worth so much: (among other things) they have seen how debt evolves over time, and may see the early signs).
You can and should design for change, within reason, because all successful programs will need to change in ways you cannot predict
You’ve yourself here. You can not predict how it wull change. Which means that whichever design for change you’ve made, may just as well completely miss the future utilization
Which doesn’t mean that we shouldn’t design for change at all… Just saying.
As long as loose coupling, and separation of concerns are well tinkered into your application you minimise risks of breaking everything on a restructuring.
If you have for example shared state leaking everywhere into the program, your most probably doomed on the slitest changes.
I am not saying you’re wrong, but there are ways to mitigate the risks even without knowing what will happen in the future.
Have you ever been in an old house? Not old, like, on the Historic Register, well-preserved, rich bastard “old house”. Just a house that has been around awhile. A place that has seen a lot of living.
You’ll find light switches that don’t connect to anything; artwork hiding holes in the walls; sometimes walls have been added or removed and the floors no longer match.
Any construction that gets used, must change as needs change. Be it a house or a city or a program, these evolutions of need inevitably introduce complexity and flaws that are large enough to annoy, but small enough to ignore. Over time those issues accumulate until they reach a crisis point. Houses get remodeled or torn down, cities build or remove highways, and programs get refactored or replaced.
You can and should design for change, within reason, because all successful programs will need to change in ways you cannot predict. But the fact that a system eventually becomes complex and flawed is not due to engineering failures - it is inherent in the nature of changing systems.
My 100 year old house has marks on the floor that look like it was worn from a door swinging. Very distinctive arc pattern. Like it was there for many years and was under frequent use.
The problem is that there’s no door there, just a wall, which is also the edge of a dormer…so if there were a door there it would just open out onto a sloping roof.
Every time I register it I contemplate why it’s there and wtf happened.
There was most likely a closet or other crawl space storage area there. My house has closets like that but luckily full height entries to them so we can actually step in. I’ve seen other houses with 1/2 or 1/3 height doors leading to under-roof crawl spaces for storage.
it is not. It’s just that there will be some point, where you need significant effort to keep the systems structure up to the new demands {1}. I find the debt-metaphor is quite apt [2]: In your scenario the debt accumulates until it’s easier to start fresh. But you can also manage your debt and keep going indefinitily. But in contrast to financial debt, paying of technical debt is much less obvious. First of all it is pretty much impossible to put any kind of exact number on it. On the other hand, it’s very hard to tell what you actually should do to pay it off. (tangent: This is why experienced engineers are worth so much: (among other things) they have seen how debt evolves over time, and may see the early signs).
[1] https://tidyfirst.substack.com/p/the-openclosedopen-principle
[2] https://blog.pragmaticengineer.com/tech-debt/
You’ve yourself here. You can not predict how it wull change. Which means that whichever design for change you’ve made, may just as well completely miss the future utilization
Which doesn’t mean that we shouldn’t design for change at all… Just saying.
… Saying what, exactly?
I said that we should
And you argued… The same thing? Just in the reverse order?
Seems like he’s worried you’ll Java everything up, which can be valid.
I think a good, easy example is whether your application should allow a selection of databases or be tied to one database.
You can make arguments for either, often (but not always) regardless of your use case.
As long as loose coupling, and separation of concerns are well tinkered into your application you minimise risks of breaking everything on a restructuring.
If you have for example shared state leaking everywhere into the program, your most probably doomed on the slitest changes.
I am not saying you’re wrong, but there are ways to mitigate the risks even without knowing what will happen in the future.