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.

[–] [email protected] 4 points 8 months ago (5 children)

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.

[–] swordsmanluke 5 points 8 months ago (1 children)

Just saying.

.... Saying what, exactly?

I said that we should

design for change
"within reason"
because we can't know what exact changes are needed.

And you argued... The same thing? Just in the reverse order?

[–] [email protected] 1 points 8 months ago

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.

load more comments (3 replies)

load more comments (10 replies)