3 ms·

If a post-mortem follow-up task is not picked up within a week, it's unlikely to be completed at all. This one is literally a law of physics. People give talk

If a post-mortem follow-up task is not picked up within a week, it's unlikely to be completed at all. This one is literally a law of physics. People give talks at conferences not to convince others that their work is awesome and totally worth the time and effort they put in, but themselves. I would add: "If you see a big name company give a talk about some cool thing they made, it's probably already been abandoned by that company." Turning things off permanently is surprisingly difficult. If you don't have a plan to sunset whatever you're building, you're basically telling your future self to go fuck himself. Unless you plan to quit first, in which case you're telling your successor to go fuck himself. The source you're looking at is not the code running in production. ((cries)) Mandatory code reviews do not automatically improve code quality nor reduce the frequency of incidents. The primary purpose of mandatory code reviews - without a sensible plan of who, when, why or how - is just for people to nitpick your code.

powerhour 4y ago
> I would add: "If you see a big name company give a talk about some cool thing they made, it's probably already been abandoned by that company." Alternatively, the talk should be viewed as the company recruiting someone to replace said cool thing.
marcosdumay 4y ago
A "plan to sunset" something looks like an incredibly alien concept to me. How do you do it when people keep finding new uses for whatever it is?
- WJW 4y ago
  With careful change management and access control. It's easy to turn off a system if you know for sure that nobody is using it anymore. Large companies and militaries do it all the time just fine so there is no reason a dynamic young startup shouldn't be able to do it. :) (As a non-sarcastic response: back when I was an officer in the navy, how we would get rid of systems was most definitely taken into account from the very start. Even before we started building ships or radars or whatever, budgets and dock space would be reserved ~30 years into the future to do the decommissioning work. I do realize that this works much better for established organizations that can be reasonably sure that they will exists in 30 years, after all most startups are hard pressed to last even two. That said, completely disregarding any planning on how to grow out of your current systems does seem to have been the case at all the startups I have consulted for and was a major part of technical debt. IMO a technical leader should know where the skeletons are hidden in the setup for their organization and know roughly in how many months/years they will no longer suffice. Then they can plan the replacement and/or upgrading of said skeletons accordingly)
- KineticLensman 4y ago
  > How do you do it when people keep finding new uses for whatever it is Assuming there is an upgrade path it does make sense to plan to turn a thing off. The thing may consume resources / facilities that could be redeployed, operators could become available for other tasks (or require retraining, etc), or the controlling organisation might need to be restructured. There might be regulatory implications / costs, such as recycling or disposal of controlled substances etc. If a retired thing is 'pure software', disposal might be simplified, but if it has physical or facilities elements (as per military capabilities mentioned by a sibling poster), disposal can be decidedly non-trivial.
- 0xbadcafebee 4y ago
  It's very hard, for that very reason that more of an organization will depend on it over time, making it harder to extricate from it. But there's a number of things that help. 0. Ownership. Try to manipulate the business to put this project under a part of the org where it's very hard for anyone to have leverage over you, so you can fight back when they try to pressure you to keep it going with no budget or staff. (Can you put it under "finance" or "admin" or "HR"? They won't give a shit about your project and aren't responsible to the tech leadership. Sometimes "IT" is the same.) 1. Money. Assign a fixed budget that runs out after X time. Put yourself in a position that you have no way to ask for more money, so they can't keep trying to stretch your team out with no additional funding. Calculate how much it'll cost the business to try to support it past EOL and put that figure where everyone can see it. 2. Limits. Design in very specific quotas and limits that give very reliable but limited functionality. If somebody wants this to scale 100x, show them how it literally can't. Prevent stakeholders from trying to do more than is possible. If they want fewer limits, tell them to give you money out of their budget to build and staff a single-tenant version of it. They will quickly go away, probably to (poorly) build their own version of it. 3. Disclosure. Tell all stakeholders what this thing can and can't do, that you won't be able to scale, what your SLA is, when this thing will be EOL and that they need to put on their calendars now to work to move off of it in time. Do not tell them the actual EOL date, tell them a date 6 months before the actual cut-off date. Communicate often and via various means in public places, because most people will never read anything they aren't interested in. 4. Stakeholder management. Tightly control who is using your system and what they're using it for. Document the downstream business risk. Make a big stink if somebody starts using your dinky little project with no funding for something mission critical. Remind them of how your limits and budget and SLA and design are all tied together and can't be worked around without redesigning the whole thing. 5. Transition planning. When your system goes away, something needs to take its place. At design phase, incorporate a timeline that includes a large chunk of time just for supporting getting people off the platform. Also plan for how you could offload the entire system onto some other system. Create a document that lists what a new system will need to have, so whoever is tasked with that will not build something that is impossible to transition to. At sunset time, redirect work towards the transition. Have a solid change management plan and get stakeholder sign-off. 6. Rigorously track the value created by this thing, or the value lost by trying to maintain it past its sunset date, and all business risks. Collect hard data. You will need it later to argue to senior leadership why keeping this thing online is a terrible idea.
hackernewds 4y ago
> you're telling your successor to go fuck himself. or themselves* :)
deleted 4y ago
[deleted]
tayo42 4y ago
> I would add: "If you see a big name company give a talk about some cool thing they made, it's probably already been abandoned by that company." Watching this happen was insane. Some team kept giving talks about how great their thing is that no one in the company was using. Major conferences immediately lost credibility seeing that happen. Sometimes it feels like everybody is just bullshitting, maybe because it really is like that.
- darkwater 4y ago
  [unpopular opinion] It's not probably true for everybody and everything, but (tech) conferences tend to attract a lot of bullshitters on both sides (speakers and public).
- oldandboring 4y ago
  AWS re:Invent just read your comment and quietly backed away...

powerhour 4y ago

> I would add: "If you see a big name company give a talk about some cool thing they made, it's probably already been abandoned by that company." Alternatively, the talk should be viewed as the company recruiting someone to replace said cool thing.

marcosdumay 4y ago

A "plan to sunset" something looks like an incredibly alien concept to me. How do you do it when people keep finding new uses for whatever it is?

WJW 4y ago
With careful change management and access control. It's easy to turn off a system if you know for sure that nobody is using it anymore. Large companies and militaries do it all the time just fine so there is no reason a dynamic young startup shouldn't be able to do it. :) (As a non-sarcastic response: back when I was an officer in the navy, how we would get rid of systems was most definitely taken into account from the very start. Even before we started building ships or radars or whatever, budgets and dock space would be reserved ~30 years into the future to do the decommissioning work. I do realize that this works much better for established organizations that can be reasonably sure that they will exists in 30 years, after all most startups are hard pressed to last even two. That said, completely disregarding any planning on how to grow out of your current systems does seem to have been the case at all the startups I have consulted for and was a major part of technical debt. IMO a technical leader should know where the skeletons are hidden in the setup for their organization and know roughly in how many months/years they will no longer suffice. Then they can plan the replacement and/or upgrading of said skeletons accordingly)
KineticLensman 4y ago
> How do you do it when people keep finding new uses for whatever it is Assuming there is an upgrade path it does make sense to plan to turn a thing off. The thing may consume resources / facilities that could be redeployed, operators could become available for other tasks (or require retraining, etc), or the controlling organisation might need to be restructured. There might be regulatory implications / costs, such as recycling or disposal of controlled substances etc. If a retired thing is 'pure software', disposal might be simplified, but if it has physical or facilities elements (as per military capabilities mentioned by a sibling poster), disposal can be decidedly non-trivial.
0xbadcafebee 4y ago
It's very hard, for that very reason that more of an organization will depend on it over time, making it harder to extricate from it. But there's a number of things that help. 0. Ownership. Try to manipulate the business to put this project under a part of the org where it's very hard for anyone to have leverage over you, so you can fight back when they try to pressure you to keep it going with no budget or staff. (Can you put it under "finance" or "admin" or "HR"? They won't give a shit about your project and aren't responsible to the tech leadership. Sometimes "IT" is the same.) 1. Money. Assign a fixed budget that runs out after X time. Put yourself in a position that you have no way to ask for more money, so they can't keep trying to stretch your team out with no additional funding. Calculate how much it'll cost the business to try to support it past EOL and put that figure where everyone can see it. 2. Limits. Design in very specific quotas and limits that give very reliable but limited functionality. If somebody wants this to scale 100x, show them how it literally can't. Prevent stakeholders from trying to do more than is possible. If they want fewer limits, tell them to give you money out of their budget to build and staff a single-tenant version of it. They will quickly go away, probably to (poorly) build their own version of it. 3. Disclosure. Tell all stakeholders what this thing can and can't do, that you won't be able to scale, what your SLA is, when this thing will be EOL and that they need to put on their calendars now to work to move off of it in time. Do not tell them the actual EOL date, tell them a date 6 months before the actual cut-off date. Communicate often and via various means in public places, because most people will never read anything they aren't interested in. 4. Stakeholder management. Tightly control who is using your system and what they're using it for. Document the downstream business risk. Make a big stink if somebody starts using your dinky little project with no funding for something mission critical. Remind them of how your limits and budget and SLA and design are all tied together and can't be worked around without redesigning the whole thing. 5. Transition planning. When your system goes away, something needs to take its place. At design phase, incorporate a timeline that includes a large chunk of time just for supporting getting people off the platform. Also plan for how you could offload the entire system onto some other system. Create a document that lists what a new system will need to have, so whoever is tasked with that will not build something that is impossible to transition to. At sunset time, redirect work towards the transition. Have a solid change management plan and get stakeholder sign-off. 6. Rigorously track the value created by this thing, or the value lost by trying to maintain it past its sunset date, and all business risks. Collect hard data. You will need it later to argue to senior leadership why keeping this thing online is a terrible idea.

hackernewds 4y ago

> you're telling your successor to go fuck himself. or themselves* :)

deleted 4y ago

[deleted]

tayo42 4y ago

> I would add: "If you see a big name company give a talk about some cool thing they made, it's probably already been abandoned by that company." Watching this happen was insane. Some team kept giving talks about how great their thing is that no one in the company was using. Major conferences immediately lost credibility seeing that happen. Sometimes it feels like everybody is just bullshitting, maybe because it really is like that.

darkwater 4y ago
[unpopular opinion] It's not probably true for everybody and everything, but (tech) conferences tend to attract a lot of bullshitters on both sides (speakers and public).
oldandboring 4y ago
AWS re:Invent just read your comment and quietly backed away...