Software Architecture cheat sheet

For the past several weeks I’ve been focusing my efforts on learning how to approach software architecture. Despite my experience in developing several applications, I wanted to read and learn more about this to do a better job in the future, for our upcoming project.

I’ve read some articles and a couple of books on this topic. My goal was to extract relevant pieces of knowledge with the final goal of producing one sheet of paper with the most important points. I wanted to stick it onto the wall behind my screen so that I could refer to it with only a glance. It had to have the most important questions that I should ask myself before committing to anything important during software design.

Today, I finally condensed all I wanted to write, prepared this page, printed and glued it to the wall:

I prepared a PDF that you can download and print to put in your workplace if you like this.

Here are the points and their explanations:

Is this a “Good Idea”?

I took this one from Avoid “Good Ideas”

The really insidious thing about “good ideas” is that they are “good.” Everyone can recognize and reject “bad” ideas out of hand – It’s the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn’t necessary to meet the business need.

In other words, think if this is necessary or is it just feature creep. Software complexity increases exponentially so having twice the features makes the code complicated by much more than twice.

DRY. Don’t Repeat Yourself

DRY is a well-known software design principle. Explained in Pragmatic Programmers, it means that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

I already have an ingrained instinct about DRY. Still, I wanted to have a good in-the-face reminder so as not to forget it in a middle of a passionate idea.

Orthogonal?

In other words, how independent is this module or block from other parts of the system? Modularity in software is important. It makes life easier later. It’s easy to understand and easy to overlook.

Testable?

Think how you will test this part of the system. Is it designed in such a way that makes testing easy? Testability depends on modularity, complexity, code style. Don’t neglect testability of your system or code. Testing is important. Manual testing is good. Automatic testing is much better.

Is there another way?

This is also from Pragmatic Programmers. It contains good quotes in every chapter. Here’s one by Emil-Auguste Chartier — “Nothing is more dangerous than an idea if it’s the only one you have.”

Often, when thinking about problems we come up with a solution and run to implement it, feeling happy that we have one. Unfortunately, often the first solution won’t be the best. Think again, be creative, try a different approach. When you come up with more ideas, it will often be the case that the first one was too rushed and that the next ones are, in fact, much better.

Costs of changing this later

Consider the decision you’re about to take. What will it cost you to change it at later stages of the project? Can you defer this decision? If you’re not sure about the decision, can you design the system in such a way that changing it later will not break things and cause unnecessary work?

What if I didn’t have this problem?

This one is from Don’t Be a Problem Solver.

Because architects tend to immediately enter problem-solving mode, we forget, or rather have never learned how, to interrogate the problem itself. We must learn, like a telephoto lens, to zoom in and zoom out, in order to ensure the question is really framed properly, and that we’re not merely accepting what we’re given.

Instead of immediately working to solve the problem as presented, see if you can change the problem. Ask yourself, what would the architecture look like if I just didn’t have this problem? This can lead ultimately to more elegant and sustainable solutions.

What are facts and assumptions? Document rationale.

The last two are from Challenge assumptions – especially your own.

Best practices in software architecture state that you should document the rationale behind each decision that is made, especially when that decision involves a trade-off (performance versus maintainability, cost versus time-to-market, and so on)…

This practice is valuable because by way of listing these factors, it helps highlight assumptions that the architects may have that are affecting important decisions regarding the software that is being designed. Very often these assumptions are based on “historical reasons”, opinion, developer lore, FUDs…

In other words, if you’re designing software architecture, write down why specific decisions are made and then think what of these are facts and what are assumptions. Check your assumptions.

Facts and assumptions are the pillars on which your software will be built. Whatever they are, make sure the foundations are solid.

Download the PDF with these question to stick on your wall.

Jacob.
I’m @jacobgorban on Twitter

I think I have a million-dollar idea

Late night two days ago, before retiring to bed, I went to the bathroom, as usual. Suddenly, right there, an idea hit me, which is not as usual.

Moreover, the idea itself is not a usual one for me. It had nothing to do with computers or high-tech, for that matter. It was about the light switch to the bathroom.

You see, I have two kids. One of them is now 4 years old. She feels old enough to go to the bathroom by herself. In fact, she can do the whole procedure herself. Except one thing. Turning the lights on and off. So it happens like this:

I’m half-lying comfortably in our bean bag chair, minding my own business. She comes to me and notifies that she wants to pee. I say “Sure, let’s go”. “No, I’m big enough, I can go myself!”, she replies. I feel lucky that I no longer have to get up from the bean bag chair for this, because it’s quite an exercise, in fact. She feels grown-up.

So she leaves, arrives to the bathroom and calls me from there: “Light!”. Oh, man.

So I had this idea about designing a light switch that usually looks and behaves like a regular one. But, when you have such kids at home, you can pull a rope from there that will allow the them to pull it and turn the lights on and off. There are “pull the rope” switches like that available but I never saw one integrated with a regular light switch, so that both parents and kids could use it. And it should be retractable into the switch when the kids grow, for esthetics.

Yes, I know that kids can stand on a short footstool to make themselves high enough to reach the regular switch. Yet it’s not so comfortable. She needs to carry it between the rooms. Yes, there’s the same problem with her room lights as well.

As far as marketing of this special switch — when the expecting couple comes to the baby store to buy the needed stuff for the upcoming baby, have the seller propose these switches to them along with all the other stuff that they buy. This way they’ll be ready to pull the rope on the first “I can go to bathroom alone”.

And the kid will also feel more empowered since she doesn’t need to ask for your help and spoil her achievement.

So here, take the idea and make a million bucks if you believe it’s worth it. I don’t know anything about designing, manufacturing and selling commodity hardware. I’m just a software guy. Pressing keys on the keyboard is all I know.