Automation - The Practice of Cloud System Administration - page 269

might be needed someday. We call this practice “futureproofing” and justify it by suggest-
ing that it will save us time in the future when the feature is needed. It is fun and exciting
to go beyond the requirements of what we are creating.
In reality, history teaches us that we are bad at predicting the future. What we think will
be needed in the future is wrong 80 percent of the time. Extra code takes time to devel-
op. In an industry where everyone complains there isn't enough time to do their work, we
shouldn't be creating extra work. Extra code is a burden for people in the future who will
have to maintain the code. A program that is 20 percent larger because of unused code is
more than 20 percent more difficult to maintain. Writing less code now saves your entire
team time in the future. The vast majority of coding involves maintaining and adding fea-
turestoexistingcode;rarelydowestartanewprojectfromscratch.Giventhisfact,making
maintenance easier is critical.
Unused code tends to include more bugs because it doesn't get exercised or tested. If it
is tested, that means we spent time adding the tests, the automated testing system now has
more work to do, and future maintainers will be unsure if they can delete a feature because
all the automated testing “must be there for a reason.” When the feature finally is needed,
possibly months or years in the future, new bugs will be discovered as the requirements
and environment will have changed.
That said, there is some reasonable future-proofing to do. Any constant such as a host-
nameorfilename shouldbesettable viaacommand-line flagorconfigurationsetting.Split
out major functions or classes into separate libraries so that they may be reused by future
programs.
There are three tips we've found that help us resist the temptation to future-proof. First,
use test-driven development and force yourself to stop coding when all tests pass. Second,
adding TODO() comments listing features you'd like to add often reduces the emotional
need to actually write the code. Third, the style guide should explicitly discourage excess-
ive future-proofing and encourage aggressively deleting unused code or features that have
become obsolete. This establishes a high standard that can be applied at code review time.
12.8 Multitenant Systems
Multitenancy is the situation in which one system provides service for multiple groups,
each compartmentalized so that it is protected from the actions of the others.
Better than creating automation for just your team is finding a way to automate
something in such a way that all other teams can benefit from it. You could provide the
software releases internally so that others can run similar systems. Even better, you could
create your system such that it can serve other teams at the same time.