I'd go down different routes, depending on what the software system was for. Every software system is about translating the work of some humans into the rules

I'd go down different routes, depending on what the software system was for. Every software system is about translating the work of some humans into the rules that some body of humans cares about. As an example, let's take something that we humans like to do a lot: buying things. So let's design an in-person payment system. Select item to buy, pay for item. Totally simple, right? So the first iteration uses a touchscreen kiosk? In twenty-to-ninety years, that will look soooo dated as everyone is paying with their hand gestures or their minds. ("Ma, I'm blinkin but it ain't buyin!") The part of the system that lives for 100 years needs to have no concept of a user interface. So you produce abstractions, you define a boundary to your system that is described as simply "user submit payee details". Now that bit can be swapped out - as long as it receives a valid user payment bundle, we're good. What about currency? Not too long ago, some countries moved from a coinage-based pounds-shillings-ha'pennies system to one based on hundredths of a pound. Soon after, many european countries banded together and moved to a single currency, still based on hundredths though. Next step might be to pay via bitcoin, at which point each mundane transaction will probably cost trillionths of a satoshi, and we'll come up with some system for calculating what order of magnitude your payment is, just to save us typing out all those zeros. So we might be representing money as 1.8265e-972. Maybe we'll write it as 18\927. Maybe it'll all be emoji, and in discussion we just call it "18 breads". Maybe society will have collapsed and we're paying with bottle tops. Two Buds and a Pepsi. Whatever we do, how we represent the cost will either need to be so vague that we can never do any calculation on it, or again, we farm the representation and manipulation to another system that doesn't need to last for a century. In the end, our program looks like: ask_user_what_they_want_to_buy => find_price_of_users_basket => take_payment => inform_user_of_success And that's all assuming that users in the future leave their homes (could be radiation), exchange money for goods (could be post-scarcity) or that there is such a thing as a company, much less that the company that commissioned the system even exists. So my answer is probably give up and do something easier. Aim for 20 years. You'll still fail, but at least the failure will cost less.