Give Your Metrics an Expiry Date
Posted3 months agoActive3 months ago
adrianhoward.comTechstory
calmpositive
Debate
60/100
MetricsData AnalysisSoftware Development
Key topics
Metrics
Data Analysis
Software Development
The article suggests assigning expiry dates to metrics to ensure they remain relevant, sparking a discussion on the broader application of expiry dates to other aspects of software development and beyond.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
5d
Peak period
14
120-132h
Avg / period
6.7
Comment distribution20 data points
Loading chart...
Based on 20 loaded comments
Key moments
- 01Story posted
Oct 15, 2025 at 8:21 AM EDT
3 months ago
Step 01 - 02First comment
Oct 20, 2025 at 6:55 AM EDT
5d after posting
Step 02 - 03Peak activity
14 comments in 120-132h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 20, 2025 at 9:52 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45591288Type: storyLast synced: 11/20/2025, 12:35:35 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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
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.
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.
Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.
Keeps from changing up too often but also gives a conscious evaluation.
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.
Or less politely, make it future citizens’ and another administration’s problem.
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.
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.)
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.