My goal is to help you minimize the unknown unknowns about software design and architecture by first discovering the goal of the software, then identify the fundamental, undeniable truths about software design and architecture that enable us to meet those goals.

Let’s talk about you

I don’t think I actually got the chance to welcome you to the world of software architecture and design.

If you’re here and you’re reading this, it’s because someone has entrusted you to take part in writing code on something that matters, or you’re deeply invested in your own growth as a developer and would like to learn how to write code that does more good than bad.

You’re the kind of person that when it comes to writing code, getting the jobdoneisn’t enough for you. Getting it done well is equally essential.

You’re also the kind of person that’s well aware that the actual act of coding itself is easy. You could say it’s just typing. Moreover, anything is easy if it’s not subject to a certain standard of quality.

What’s hard is producing software that’s

•  Simple
• Clean
• Satisfies the needs of its users today
• Can be changed to satisfy the needs of its users tomorrow 

That’s hard. That’s also the primary goal of software.

The goal of software

To dive into the depths of what makes software good, let’s understand the goal of software.

The goal of software is to continually produce something that satisfies the needs of its users while minimizing the effort it takes to do so

Whether it be a clock, a note-taking app, or even the code that runs on Java in your washing machine, goal #1 is to satisfy the users’ needs.

Goal #1 of software: Satisfy the users’ needs.

Does the software meet the needs of its users? Yes? Awesome!

Now, if we can accomplish that impressive feat at least once, goal #2 is to figure out how we can consistently achieve goal #1- over and over, with minimal development effort.

Goal #2 of software: Consistently accomplish Goal #1, with as minimal development effort as possible.

That’s usually the tricky part. This is where code quality and design start to matter. Cleaner, simpler, and generally better-designed code is a lot easier to take from point A to point B than brute-forced code that serves the initial needs of the users.

It’s not as black and white as I’m making it sound, though. Satisfying the users’ needs is incredibly subjective. Here’s what I mean.....

Users’ technical expectations vary based on their needs

Depending on the application, what it does, how users intend to use it, and how badly users actually need it, their technical expectations will vary.

Let’s look at a few examples.

First one. Let’s consider the technical expectations of a machine-learning application that, with AI, was able to take your old VHS home videos and (drastically) improve the picture quality.

AI-Improved Home Movies: Users might be OK with the rendering process taking 2 hours to complete (- speed), as long as it always works (- reliability).

However, users might not be OK with it taking long (- speed) AND falling victim to render jobs occasionally failing around the 1 hour, 15 min mark (- reliability).

Another example, a common one, is being able to tap your debit card to pay instead of having to insert or swipe (I believe the actual name for this is called Contactless Payment).

Tap-enabled Debit Cards: Buyers are able to pay for things by tapping their debit card on the merchant’s card-reader, removing the need for the buyer to type their pin every time they make a purchase (- speed, - efficiency).

Older models readers don’t have tap built-in, so a software upgrade won’t work. Replacing the reader is the only option (- adoptability). Even still, for buyers, there are a fair amount of merchants with readers out there that do accept tap, so it’s worthwhile to have a tap-enabled debit card

If cards were easy to hack, as in, if it were trivial for someone to create a fake payment reader and bump your pocket with it (- safety), that may drastically affect the technology’s adoption rate, and the opinion of it being good software.

One more example. It’s actually based on a scenario I’m intimately acquainted with.

Real-time online job fair: Consider you’ve been asked to build a real-time online job-fair system.

Your client currently runs a popular forum (hacked together with Wordpress) where people can find co-founders and learn how to build a startup.

Once every month, your client wants to run an online job-fair featuring one or more startups. Job seekers should be able to join the chatroom, ask questions, and make connections with recruiters from the startup companies that attend the event.

They’ve been able to run a couple of these events without any problems on some very cheap shared hosting.

The reason why you’re being asked to work on this project today is that the last event had over 500 people in a chatroom at one time. During that time, several users complained about

lag and messages taking a long time to send.

Your client has no plan to stop growing. Eventually, he wants to host online events containing over 50,000 concurrent users. 

How will the user (and business) needs affect the resulting code? 

It appears that scalability is of primary concern to your client (and the continued success of the business, overall). Meanwhile, for the users, responsiveness is of primary concern. They want it to feel snappy (- responsiveness). 

If you take the gig, you’re tasked with figuring out the best way you can organize code to fulfill those needs.

System quality attributes (SQAs)

In each project example, there was a set of metrics that needed to be satisfied to make the users happy. 

Those metrics, like speed, reliability, availability, and scalability, are what we callsystem quality attributes (SQAs).

Here’s an entire list of software quality attributes for you to check out if you’re interested.

How do we design a project to be successful?

When starting a new project (like any of the ones listed in “Users’ technical expectations vary based on their needs”), I listen very carefully to the problem statement. 

But most importantly, I keep my ear peeled to pluck out those essential SQAs in between the lines.

Those SQAs are going to signal to you what is most important for the system to succeed, what has the most significant potential to make the system fail, and what architectural choices will stack the odds of success in your favor.

Aren’t all system quality attributes essential?

If we designed a system that possessed all of the positive SQAs to a very high degree of effectiveness, and none of the negative ones, it just might be asymptotically perfect.

But achieving that is both very hard, and also probably not necessary to the business.

Realistically understanding that we can’t be good at everything right off the bat, depending on what the system is supposed to do, only some of these are critically system quality attributes essential.

Identifying those will help us make some of those big up-front decisions.