[sandermvanvliet]

I think this should be true for many things, or at least have a fixed future date at which you re-evaluate $thing

For example with Architecture Decision Records, put a 6 or 12 month expiry on them and evaluate to see if they can be renewed, should be changed or replaced with something that covers new insights.

Unfortunately that seems a very unpopular thing to do so I’ve never seen it work and companies end up with “we have always done it like this” type practices

[bluGill]

You cannot usefully change/review architecture decisions in 1 year. The point of architecture is to make the hard decisions that you will regret getting wrong in the future to try to get them right now (often without enough information to make them). If you decide to make a free for all an architecture will emerge that is a mess that you cannot change.

Architecture should not be "we have always done it like this". If you don't write down why though it will become that. Often there are good reasons that things have always been done like that - those reasons may or may not still be valid but if you don't know what they are it is hard to evaluation. More than once I've seen someone rethink a "we have always done it like that" and discover the hard way why they always did it that way.

I've never seen a company with a good way to write down why they do things though. When someone even tries nobody reads those documents.

[scaryclam]

It really depends on the decision, what was done, and the overall impact. If the decision is to migrate to microservices, a year in it may be reviewed and decided that the work has been far more than anticipated, and is too much for EVERYTHING to be migrated, and the decision changed.

Or it might be an architectural decision to change the hierarchy of some organisational structure. Again, it could be the correct call for the time, but as things evolve over a year, it may not be sufficiant a year later.

A year isn't a bad time to review, and if the decision is just a "yeah, duh, of course we'll continue", then it's a really quick conversation, but at least you're thinking about things.

[bluGill]

You can review - but by the time you really know it is too late. If things are going really bad after one year then start over. However often things that will go well long term are having "growing pains" at 1 year and so "staying the course" despite the pain might be the right decision. Until you have a microservices architecture you don't know the pros/cons of it for your system - you can get insight from others, but their system will be different and so will have different problems.

Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.

[fragmede]

A year is and is not a long time, so it depends on how seasonal the prosu is. New years celebration decorations are at one end of the spectrum, but it turns out a lot of things have a seasonality to them as well.

[storyinmemo]

I've advocated for this as well but called it a lease. We agree to run this for the duration of the lease and agree to determine whether we should extend / re-sign the lease a period of time before the expiration.

Keeps from changing up too often but also gives a conscious evaluation.

[rkagerer]

It's more important to have people who actively "own" each piece of the infrastructure, and are intimately familiar with it, the rationales, the tradeoffs, etc.

Then when new knowledge/technology/idle cycles come along they can take advantage to update/refine it in sensible ways.

Often the sensible way is "leave it, it works fine". But there's a big difference between arriving at that outcome via ignorance vs. deliberation. Too often management doesn't recognize the difference, but the former as your state of affairs will eventually lead your stuff to rot.

[adrianhoward]

<nods> another of my fave things for expiry dates are regular meetings — never set them to repeat forever. Six months max. That way you have to be intentional about keeping them going & talking about their value (or not ;-)

[chanux]

IIRC Nassim Taleb proposed that every institute (or was it policy?) should come with an expiry dates. In work context there have so many things I thought this applies (meetings, policies, email alerts etc).