The Serverless Architecture Astronaut

In the fast-moving world of tech, I find it kinda comforting to rediscover evergreen realities of software development that are as true today as they were 20 years ago when I was starting out my career.

One such example is this April 2001 article by Joel Spolsky on Architecture Astronauts:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. These are the people I call Architecture Astronauts.

Know anyone fitting this description?

Shame bell time: for a few years in the mid to late 2000s, this was me 🙈 (Alas, I didn’t catch Joel’s article at the time).

Back then, I worked for a software dev house that developed line of business systems for corporate B2B clients. We had built several applications that used very similar patterns and a principal architect in the company came to me with an idea about creating an internal development framework to help accelerate development of such projects for our future clients. So young naive me got really excited and set to work creating this heavily abstracted DSL which generated code for CRUD frontend and backend components for each entity in the domain model. Our developers will ship so fast with this framework!

We piloted the framework on a few client projects and I’m sure you can guess how it went. The abstractions were far too leaky to meet the project-specific requirements, developers got frustrated, delivery deadlines passed, clients got annoyed. I got burnt out and to this day, I still get anxiety pangs thinking about it.

This was a lesson hard-learned for me, but I still see many Architecture Astronaut traits evident today. I could go as far to say that in the serverless space—where many new tools, services and patterns such as async event-driven architectures and microservices are readily available—an Architecture Astronaut is even more enabled.

Here are a few examples of Architecture Astronaut behaviours I’ve witnessed in the wild:

• Creating super generic data models citing speculative future expansion possibilities, incurring up-front cognitive load on developers.
• Trading off a slow user experience in order to maintain an elegantly decoupled microservices backend.
• Obsessively seeking re-use opportunities, e.g. writing a Lambda function in such a way that it could be invoked in different ways.
• Taking Single Responsibility Principle to the extreme via micro granularisation. One Lambda function per microservice, all in their own repos and separate AWS accounts. (see Nanoservices)

Reading through this list, it’s either the developers or end users (or both) that have to live with the negative consequences of the architect’s decision. So how do you avoid becoming an Architecture Astronaut?

If “Be more empathetic to your users and developers” is too glib, here are some prompts to use when making an architectural design decision:

• What extra cognitive load or feature delivery overhead is this putting on my developers?
• Is this a well-known or commonly used pattern/tool that new hires will be able to understand and be productive with?
• How easy will this be to debug when it inevitably breaks? And will the developer be able to do it themselves without asking you?
• How easy will this be to back out of if it doesn’t work out? Is this a one-way or a two-way door decision?
• Did I recently learn about this tool/service/pattern and get excited and want to try it out on a real project? This might still be ok, but acknowledge that you have biases that may not be healthy for your team/product, and proceed with caution.
• Discuss your decision with other developers or colleagues that aren’t afraid of being frank with you before committing.

And if after all of this, you’re still in doubt, apply KISS and YAGNI.

— Paul