How to selfishly design a system
Your primary constraint is your pride
There are a lot of ways to design a system. Gathering input. Talking to customers. Looking at other systems with similar requirements. Figuring out the requirements. Guessing what the requirements will be. Waiting for the requirements to arrive. Sitting down and thinking about what the requirements could be. Drawing pictures. Wondering what your high school art teacher would think of the pictures.
Values
Eventually, you need to stop waiting on input and make something. Designing a system is an optimization exercise with multiple factors. You want to create a system that can be built now, will run in the future, and doesn’t cost too much to operate. The system should be able to be changed. It is a very complex assignment; it is easy to overthink it.
It helps to have some general guiding values that help narrow down the possibilities.
Traditionally, the values that drive a system are descriptions of its properties once it is built. These values have cool names and are often used in sentences with cool words like pillar and architecture1. I’ve heard these referred to as “the abilities,” so I’ve put this postfix on each one to show how bad this nickname is.
Reliability: how often you get the right answer when you ask the system a question
Availability2: how often the system is able to answer when you ask
Scalability: how much the first two change after you run Superbowl ads
Sustainability: how often hippies are protesting outside your building
Operability: how easy it is to go the opera and not get paged
Simplicity: how few of these -lity you mention when describing your system
Maintainability: how often people resign after failing to convince you to rewrite. Also called pliability, extensibility, evolvability, plasticity3
Securityability : how often you have to say risk mitigation to someone more dressed up than you
Observability: a complex measure of your cloud operating budget
Operational Efficiencyability: how many non-engineers it takes to keep everything running
Litylity: how easy it is to add -lity to a word and it still makes sense
Tradeoffs
The nature of this game is that these items are tradeoffs. You have to weigh one thing against another. Often, a highly available system is very expensive and difficult to operate. A highly secure system is harder to maintain, less observable, and likely not simple. You are creating trouble where you want trouble; you choose what things you want to be easy, hard, or possible.
Personal Values
Writers only write autobiographies, even if they are heavily cloaked. In the same way, this content management system for dog moms you are building also reflects who you are and what you value.
Maybe you think that new things are almost always better than old things.
Maybe you value safety in the workplace and leave risk-taking to your investments.
Maybe you want to impress people, or not draw attention.
Maybe you believe cat dads are more important to society than dog moms.
These values will emerge in your system design, so you might as well optimize for those that will help you personally. Designing a system that tries to account for all the system ilities while also guessing at the future is no way to live life. It's stressful and hard and doesn’t make you feel good.
Speaking of you - you need to look out for #1. Yourself. What values do you have?
You should build a system based on YOUR personal values.
Below are some selfish values to use when designing a system:
Enviability
Your system design needs to be cool. It needs to invoke envy in those around you. Maybe it’s your boss, the Architect Of The Original System, or the Council of Certified Solutions Architect Advisory Designers Who Are Quiet and Judge You. Maybe it is just the person who reviewed your last pull request. It also needs to impress your regular coworkers, so much so that they stare out the window and try to calm their envy. They wish they weren’t writing a React app to track tool vendor usage for internal users, but that they were instead on the team rewriting the tool vendor usage for internal users in a different javascript framework that nobody will remember 50 years from now.
Marketability
Designing this system will go on your resume. Will it make for a good blog post, or LinkedIn humble-brag? How easy will it be to discuss in a future job interview? If it uses boring technology, then you will be a boring job candidate. If it pretty much works, you will not have any cool stories. Let your resume drive the design.
Fragility
To be anti-fragile, you first have to be fragile. It’s like winning the Most Improved Player award in the NBA - you have a crappy season, then a good one. If your system starts as fresh garbage and requires your constant intervention, you become critical to the project and keep your job. Ship a working prototype and then evolve it into something real.
Civility
What architecture does your boss, VP, or CTO like? What pet project does an influential Enterprise Solutions Architecture Council of Wisdom member like? Pick one to have good manners.
Adorability
How fun is writing a prototype for this new system? How fun will the first 3-6 months of the project be? How novel and, therefore, interesting will this project be? How cute is the code in your examples? Don’t worry about 3 or 6 months from now, how interesting is it now?
Deniability
You could get into trouble if you design a system that causes a snafu or fiasco4 . You might ultimately lose your job and have to design systems somewhere else for slightly more money. Can you weakly defend your choices while also denying them? Directly denying that you were involved in the construction of the system is tough, because of all those pretty pictures you drew. But a defend & deny strategy works:
Use a large vendor: “Nobody ever got fired for using IBM”. Use Microsoft, AWS, Google, and others everyone seems to have heard of.
Teamwork makes the dream work: remember that tens of other people likely loved your design too. Make sure to get their approval, preferably on video, while they discuss current events.
Communicate that your vision was not followed: “The programmers didn’t build it to specification. Look on Page 7:
System will have no known defects at launch”Spin: “wow imagine how much worse this would be if we had done TRW”
We are obsessed with physical construction as a metaphor. Eventually, stanchion (an upright shaft that supports an overhead structure) will be used to describe code written by someone who is now a VP that everyone is afraid to touch.
Coaches say, ‘Your greatest ability is your availability.’ This does not prove true for systems. Imagine if TurboTax had 100% availability but got everyone’s taxes wrong.
That is a lot of words for the concept of something being easy to change. Why would system designers have so many words for something?
snafu: a situation marked by errors and confusion.
fiasco: a thing that is a complete failure, especially in a ludicrous or humiliating way.
If you lose your balance and step in a toilet while going to the bathroom - that’s a snafu. If you somehow step in a toilet during your wedding vows - that’s a fiasco.