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
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.
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.
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.
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.
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).
<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 ;-)
I’m not sure if you’re joking or you’re thinking of a different type of “metric.”
The metrics I think you’re referring to are the ones you collect throughout your product, which I think the article author would advocate you continue to collect and expand.
The “metrics” the article references is more actively tracking and referring to them in your workflow. So, tracking and acting on changes to conversion rate. If you “expire” them, you don’t stop collecting them, you just take them off your dashboard for now.
Isn't that a big part of the issues the US has with passing a budget? Some of their tax breaks etc. have expiry dates so keep needing to be renewed. I think part of the current shutdown is related to the debate about renewing the obamacare tax breaks which have/are due to expire
So they do the thing where they set breaks to sunset in order to make the bill revenue neutral according to the CBO.
Then, later on, when the tax breaks are ready to sunset, they convince the CBO that the tax breaks constitute the new baseline. So now when they pass the next budget they are not considered "new" and they do NOT need to be balanced with cuts or increases any more.
It's a total end run around the intention of the process.
very true, although in relation to OPs point I was talking less about the why of expiring laws/taxes and just pointing out that creating laws that expire can have its own less than desirable knock on effects
To over simplify the process: Budgets in the US are supposed to be revenue neutral. The use of sunset provisions, like the SALT cap, allow Congress to play with the math in order to make it follow its own rules. These provisions are really a gimmick because not extending them before expiration becomes a political problem. I.e. letting the SALT cap expire would “give the rich a tax break”. Note: I’m not arguing the validity of the SALT cap).
> Budgets in the US are supposed to be revenue neutral.
To clarify - budgets passed via the reconciliation are supposed to be revenue neutral. The reconciliation process takes away the Senate's filibuster. When the filibuster is in play, it effectively requires a 60-40 supermajority to pass anything.
(No this is not how the founders imagined the process going when they wrote the rules.)
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
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.
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.
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.
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.
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).
<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 ;-)
If you have the time to evaluate your metrics on a case by case basis every 18 months, you aren't collecting enough metrics
I’m not sure if you’re joking or you’re thinking of a different type of “metric.”
The metrics I think you’re referring to are the ones you collect throughout your product, which I think the article author would advocate you continue to collect and expand.
The “metrics” the article references is more actively tracking and referring to them in your workflow. So, tracking and acting on changes to conversion rate. If you “expire” them, you don’t stop collecting them, you just take them off your dashboard for now.
I wish laws had expiry dates. For 100 years. Inertia seems to be the most powerful force
Isn't that a big part of the issues the US has with passing a budget? Some of their tax breaks etc. have expiry dates so keep needing to be renewed. I think part of the current shutdown is related to the debate about renewing the obamacare tax breaks which have/are due to expire
I think that’s as much a matter of game-playing to be able to give breaks now and make the budget impact evaluation work out by making them temporary.
Or less politely, make it future citizens’ and another administration’s problem.
They recently stepped up their game.
So they do the thing where they set breaks to sunset in order to make the bill revenue neutral according to the CBO.
Then, later on, when the tax breaks are ready to sunset, they convince the CBO that the tax breaks constitute the new baseline. So now when they pass the next budget they are not considered "new" and they do NOT need to be balanced with cuts or increases any more.
It's a total end run around the intention of the process.
very true, although in relation to OPs point I was talking less about the why of expiring laws/taxes and just pointing out that creating laws that expire can have its own less than desirable knock on effects
To over simplify the process: Budgets in the US are supposed to be revenue neutral. The use of sunset provisions, like the SALT cap, allow Congress to play with the math in order to make it follow its own rules. These provisions are really a gimmick because not extending them before expiration becomes a political problem. I.e. letting the SALT cap expire would “give the rich a tax break”. Note: I’m not arguing the validity of the SALT cap).
> Budgets in the US are supposed to be revenue neutral.
To clarify - budgets passed via the reconciliation are supposed to be revenue neutral. The reconciliation process takes away the Senate's filibuster. When the filibuster is in play, it effectively requires a 60-40 supermajority to pass anything.
(No this is not how the founders imagined the process going when they wrote the rules.)
i think it's more they just tack on a bunch of unrelated stuff into bills that "must" be passed
A technical term for this is "sunset provision": https://en.wikipedia.org/wiki/Sunset_provision
[dead]