this post was submitted on 12 Apr 2024
797 points (98.8% liked)

Programmer Humor

26052 readers
1287 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 71 points 1 year ago (13 children)

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 1 year 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.

[–] [email protected] 6 points 1 year ago

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.

load more comments (4 replies)
load more comments (11 replies)