Hey friends 👋 I hope you had a fantastic weekend full of fun, adventures, and enough rest for the week ahead.

I’m really excited about today’s issue because we have a little sneak peek at one of the topics we’ll cover in my upcoming Fundamentals of Frontend Architecture workshop—including one of the templates we’ll use to define our project’s requirements.

Speaking of which, I’m thinking about starting a Discord server for the workshop that we could also use to just hang out and chat about frontend stuff. If that sounds interesting, let me know by replying to this email and I’ll share an invite link in the next issue :)

Alright, let’s jump into today’s newsletter!

SOFTWARE DESIGN

The Least Worst Architecture

Whenever I feel overwhelmed by the infinite number of decisions I have to make in a software project, I like to come back to this piece of advice by Neal Ford and Mark Richards in Software Architecture: The Hard Parts:

“Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.”

That’s quite liberating, isn’t it? But still, it’s easier said than done—with thousands of tiny decisions to make, finding the least worst combination of trade-offs is very much a challenging task.

Luckily for us, software architects have several tricks up their sleeves that can help make this job a little easier. So this week we’re going to borrow some of their wisdom and talk about a few of them, including

• Architectural Drivers,
• Architectural Requirements,
• Architectural Decisions, and
• Architectural Digest

Wait, that doesn’t sound right—I think that last one sneaked in from a different list. Anyway, get ready to see the word “architectural” a lot today.

What Influences Your Architecture?

Let’s start with architectural drivers—the influencers of your architecture. They’re a lot like Instagram influencers but without the massive following and like, 99% less glamorous.

Whether you choose to listen to these drivers or not, they will have a say in your architectural decisions, so it’s important to be aware of them.

Here are some of the most common ones:

• Business Goals — Business goals tell you why the project exists in the first place. These could include product or business-related goals (like increasing adoption of features, increasing revenue, or cutting costs), but also your user’s goals, such as saving time or being more productive by using your product.
  ​
  Avoid the temptation to overlook business goals. I know they might seem unrelated to your architectural decisions, but they’re crucially important. You might come up with the most beautiful of designs, but it’d still be a failure if it doesn’t meet your business goals.
  ​
• Constraints — Constraints are the non-negotiable aspects of your project. You should welcome constraints with open arms, because they’re decisions that are already made for you. They limit your options, but they can also simplify your problem by giving you fewer options to explore.
  ​
  Constraints come in different shapes and forms, but largely they fall into two categories: technical and business-related. A technical constraint could be, for instance, that you must use Vue.js for your project because your component library is already built with it. A business constraint is typically related to legal matters (anything contractual) or, commonly, time and money.
  ​
• Quality Attributes — Quality attributes define what’s the “important stuff” for your architecture. You might also know them as architectural characteristics, or the -ilities of your system: scalability, reliability, maintainability, performance, and so on.
  ​
  It’s not possible for an architecture to optimize for every quality attribute, so choosing and prioritizing the most relevant ones for your project is critical. The priority of your quality attributes (e.g. is performance more important than scalability?), will guide a lot of your architectural decisions.
  ​
• Influential Functional Requirements — Functional requirements define the system’s behavior and the things users can do with it. But not every functional requirement is an architecture influencer, so it’s important to dig for and identify the ones that are architecturally significant.
  ​
  For instance, the functional requirement “users should be able to update their first and last name” is not particularly interesting from an architectural perspective. But if the requirement is “user name updates should be broadcast in real-time to all of the user’s followers”, then that will almost certainly have an impact on the architecture.
  ​
• Other Influencers — There are a bunch of other things that will influence your architecture in some capacity. This includes the team’s experience and know-how (like the frameworks and languages they’re proficient with), the architect’s experience with specific patterns, and even the technology trends of the day.

There are two main reasons why architectural drivers are so important.

The first one is that they help us understand the problem we’re trying to solve. Without fully understanding the business goals of the system, for example, it’d be really easy to fall into the trap of solving the wrong problem the right way.

The second reason is that they determine our architectural requirements, which are the success criteria of our project. These are really important because they’re the only way we have to figure out if our architecture is successful or not.

Now, you might be thinking “This sounds like a lot of work, Maxi. Isn’t there a template or something that I can use to make this whole thing a bit easier?”

Well, I'm glad you asked! Because I just happen to have an Architectural Requirements Doc (ARD) template that you can copy and adapt for your next project.

The ARD is one of the resources we’ll go over in my upcoming Fundamentals of Frontend Architecture workshop, which is coming soon (or soon-ish I should say, depending on how my kids behave.)

You don't need to wait for the workshop to use the template, however; it should have enough instructions and examples for you to start using it right away. If you give it a try, I'd love to hear what you think :)

Activity Time

If you take a look at the ARD template, you’ll notice there are a couple of funny-looking tables in the appendix (trade-off sliders and decision matrix) and you might be wondering what those are all about.

These are just two of the many activities you can do with your team to help you make better architectural decisions. Let’s talk briefly about each one of them.

Trade-off Sliders

This is a popular project management tool that you can use to prioritize competing goals or requirements.

You can use trade-off sliders with pretty much anything (cost vs. quality vs. speed is a common set) but from an architectural perspective, it’s typically used to compare quality attributes.

The rules of the sliders are simple: there are as many steps in the slider as there are options to compare, and no two options can be in the same step.

Now gather your team and your most important quality attributes, and all you have to do is agree on where each slider should be at. Time to complete this activity: between 20 minutes and 600 hours (depending on how much you all like to argue.)

Decision Matrix

Another tool that can help you make important decisions is the decision matrix, which is helpful when you need to compare how different options score against your project’s quality attributes.

For example, imagine you’ve made the decision to use React for an upcoming project (perhaps there was a constraint around that), and you’re now trying to decide which rendering pattern you should use.

You’re considering three options: a traditional SPA, Islands Architecture, and client-side rendered Micro Frontends. Here’s what a decision matrix could look like based on your most important quality attributes:

On each cell, you’ll put a symbol indicating whether that option promotes a particular quality attribute (+), inhibits it (-), or if it’s neutral (o). You can also use strongly promotes (++) and strongly inhibits (–) if necessary.

This might take a while to figure out (and some more heated discussions with your team), but once you complete it, you’ll have a nice visual asset to help you make the right call and choose the best option.

Or at the very least, the least worst one.

ARCHITECTURE SNACKS

Links Worth Checking Out

📕 READ

1. Simone Poggiali wrote The Concise TypeScript Book, a completely free and open-source book that, despite having the word "concise" in its name, is incredibly detailed and comprehensive.
2. Are you going through a frontend developer identity crisis? You're certainly not alone, and you might find some comfort in this essay by Elly Loel.
3. Max Stoiber wrote about the problems that GraphQL solves, and why you might be right to think that you don’t need it.
4. If my ramblings about decision-making weren’t enough to satisfy your cravings, this article by Ben Morris has some additional interesting takes.

​

🎥 WATCH

​The Future of Programming by Bret Victor

It’s been a while since I’ve included a classic talk in the newsletter, so I thought today I’d share what continues to be one of my favorite talks of all time. Put your bell-bottom jeans on and take a trip back to the 1970s to hear about the future of programming. Just a word of caution: this talk might be the start of a very long Bret Victor binge-watching session, so make sure you clear the next three hours in your calendar just in case.

​

🎧 LISTEN

​Building Resilient Architecture with Monica Lent

You know I love a good frontend architecture discussion, and this interview with Monica Lent on the React Round Up podcast did not disappoint. It's a fun chat covering a bunch of really interesting topics, from the importance of building constraints into the architecture, to the merits of software design in frontend development. Definitely worth a listen!

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

I read and reply to all of your comments. Feel free to reach out on Twitter or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi