You are not a child anymore: you have become a parent and it is now your responsibility to keep everyone's room clean - with or without their cooperation. If something exists, it consumes resources, even if it is just attention - so it can only exist if it has a purpose, however insignificant. So keep the rooms clean - and enjoy the bonus of spotting cracks in the floor more easily.
Anything that is sitting around doing nothing is likely doing some amount of harm. For example, making backups longer, increasing the learning curve for a codebase, etc..
The room-cleaning metaphor isn't as apt as you think. The metaphor I have found most helpful, heard from several other voices, is the garden-tending one.
There's a reductio ad absurdum open in the room-cleaning premise. I could write a million lines of code that don't do any measurable harm -- calling a no-op -- and by your standard they ought not be removed. Not doing any harm isn't the same as actively contributing value, which is what most people want their codebase to do.
Thats how I ended up with 700 versions of FW. If something is not in use, archive it and make it non accessible, or someone will come along and do things with it you never intended.
I estimate I have around $200 a month in EBS costs for volumes and their backups that need cleaning up, if I can get round to it. But there's just me in my startup, and I have no choice but to leave it lying around for the moment. But the lesson is that what I spend on that in a year (if I leave it that long) will pay for a temp resource for a month easily. That's a lot of harm things lying around can do to a cash strapped startup.
Comments
Lesson 0. You are not a child anymore with your mother nagging you to clean your room. If something is doing no harm, don't delete it.
You are not a child anymore: you have become a parent and it is now your responsibility to keep everyone's room clean - with or without their cooperation. If something exists, it consumes resources, even if it is just attention - so it can only exist if it has a purpose, however insignificant. So keep the rooms clean - and enjoy the bonus of spotting cracks in the floor more easily.
Anything that is sitting around doing nothing is likely doing some amount of harm. For example, making backups longer, increasing the learning curve for a codebase, etc..
The room-cleaning metaphor isn't as apt as you think. The metaphor I have found most helpful, heard from several other voices, is the garden-tending one.
There's a reductio ad absurdum open in the room-cleaning premise. I could write a million lines of code that don't do any measurable harm -- calling a no-op -- and by your standard they ought not be removed. Not doing any harm isn't the same as actively contributing value, which is what most people want their codebase to do.
Sure, if it's not doing harm. But in this case, all this old data was really costing us:
- real costs - database storage, blob storage, (minor) perf impact
- hidden costs - tougher to create test environments that look like production if production is so large, but largely invisible / unusable.
Thats how I ended up with 700 versions of FW. If something is not in use, archive it and make it non accessible, or someone will come along and do things with it you never intended.
I estimate I have around $200 a month in EBS costs for volumes and their backups that need cleaning up, if I can get round to it. But there's just me in my startup, and I have no choice but to leave it lying around for the moment. But the lesson is that what I spend on that in a year (if I leave it that long) will pay for a temp resource for a month easily. That's a lot of harm things lying around can do to a cash strapped startup.