Learning Software Architecture; Start With Why!
What starting with why can teach us about software architecture
61,698,933!
That’s the number of views (at the time of writing) Simon Sinek’s TED talk on ‘How great leaders inspire action’ has. A fundamental idea from the talk is the idea of a golden circle, and how we default to approaching things in the complete opposite way.
Many of us approach things with an outside in approach. We start with what, take steps to work out how, and rarely worry too much about the why. This is a flawed approach. Starting with why, at least in business, explains your purpose and why you are doing the thing you are doing. People buy your why, not your what. Yet many businesses start with the what, and completely lose the sense of purpose. Your why drives the relationship with your customers.
You might wonder how this short piece of business advice relates to how we teach software. But let’s take this same golden circle, and apply it to how many of us try to learn about software architecture.
People interested in software architecture often ask me which AWS service to learn first. Or which certification to take. Do I learn about serverless or containers? Event driven architecture or microservices? These areas are inevitably ones you will need to learn about at some point, but they are unlikely to be the best the place to start.
You are starting with what! Instead, start with why.
Starting with Why
Build your knowledge from first principles. Technology iterates on itself quickly, and every iteration takes a problem seen previously and makes it better. These iterations stack on top of each other to give us the technology choices we have today.
On-Premise servers -> Elastic Cloud Servers -> Containers -> Container Orchestrators -> Serverless
The most famous saying in software architecture is it depends. Taking a specific technology driven approach, to learning software architecture limits your ‘it depends’ to the specific niche of technology you are learning. If you have a hammer, everything looks like a nail. If you have a Lambda function, everything looks like it’s event driven.
Instead of asking why exactly are we trying to hang this thing from the wall?
Let’s take databases as an example. DynamoDB is a popular, fast and flexible NoSQL database service provided by AWS. It’s actually my second favourite AWS service (just beaten by Step Functions if you’re interested). DynamoDB is largely schemaless. The schema of the items you write is determined at runtime.
What this means is that you can store almost anything in DynamoDB, in any format. It’s an incredibly flexible database that could probably fit almost any application use case.
That flexibility is one of DynamoDB’s biggest strengths, and also it’s greatest downfall if misused. If you spend all of your time learning about the specific API’s of DynamoDB, you understand single-table design, global secondary indexes, sparse indexes, read and write capacity units but never understand the why… Well then there is every possibility you may choose to use DynamoDB in a scenario where it doesn’t actually fit.
Traditional relational databases still have a perfectly valid use case in modern technology. As do graph and time series databases. There is a reason AWS (currently) has 15 different database services. Yet if you are stuck in your little DynamoDB bubble you never even look up to see what else is out there.
I’m not suggesting everyone needs to go deep on every single different type of database, but understanding the history of why we got to where we are is important. Designing Data-Intensive Applications by Martin Klepmann is an absolute goldmine for this content. Even reading the first 3 chapters of what is an admittedly dense technical book, would give you a huge architectural advantage because you understand enough to make an informed decision.
A Generalist Growth Mindset
In the excellent book Range David Epstein discusses how being a generalist is a fantastic skill to have. The cross-pollination of different ideas, from different domains, leads to better decision making and more creative thinking.
Having a general idea of the use cases for the different database options, a set of first principles that guide your decision making, forces you to start from the problem you are solving and work outwards to what database you are going to use. Suddenly, the decision between 16 different AWS database services becomes less challenging. You’re making your decision based on the specific problem domain, applying your general knowledge of all databases to work out to the best technology choice.
Once you’ve gone through the why and reached the what, it’s time to double down on a growth mindset. Professor Carol Dweck proposed the idea of fixed and growth mindsets. A person holding a fixed mindset assumes that their abilities are immutable, whereas a person with a growth mindset acknowledges that they can acquire and develop any new skill with sufficient time and effort.
Fixed = I don’t know Growth = I don’t know, yet
Baseline your thinking as a generalist and start from first principles, before doubling down on your growth mindset to pickup a new technology as and when the time arises.
Starting from why; a skill all architects, aspiring or otherwise, should cultivate at all times.
As always, thanks for reading. James