
Software architecture cheat sheet - grayprog
http://gorban.org/post/32873465932/software-architecture-cheat-sheet
======
ChuckMcM
Very nice.

I'm a big fan of #1 being "State the problem." rather than "Is this a 'Good
Idea'?" they are inter-related of course, but any good software architect has
their eyes fixed on the problem so they don't get distracted by the
opportunities to 'decorate'.

I like asking people what they think the 'architect' does, that is to weed out
people who think architect implies a leadership role, it can be but it isn't
necessarily. In the 'real' world the architect is the person who notices
you've got a banquet room for 100 people but the nearest restroom is two
floors down, or a single hallway connecting both the people and the kitchen to
the room. They see the 'whole' goal (feed large groups of people) and then
work out what has to be true for it to be not a problem.

I look for similar skills in software architects, they don't care if the
implementation is rails/django/node but they do care that individuals can be
identified as users or guests, given capabilities or not, can be disabled or
not, and the largest possible number are welcome.

Sometimes architecture is combined with the person who does design, sometimes
with the person who does coding, and sometimes its just a person asking really
good questions at the launch planning meeting.

~~~
killahpriest
What's your solution to the bathroom problem?

~~~
jerf
That's too context-specific to answer without a whole lot more questions.
Plus, if we're actually talking about code, physical metaphors break down
anyhow. First-cut answer is "move bathrooms closer"/"make the hallway bigger"
but one must also ask the question, "How did this mismatch arise in the first
place?" Anything is possible, especially in software; the hallway may in fact
be adequate and it's everything else that is grossly overspec'ed... or in
fact, you might have ended up with a poorly-designed dining room for 100
people because that's all the previous guy knew how to build, when in fact you
need a stadium for 100,000 people. (I've been there before.)

------
RyanMcGreal
I'd rather call this a checklist than a cheat sheet. A cheat sheet is a quick
lookup for someone who doesn't know what they're doing, whereas a checklist is
a quick lookup for someone who does know what they're doing and is humble
enough to recognize that even the most capable expert performs better when
working off a list.

Related: <http://gawande.com/the-checklist-manifesto>

~~~
jonsen
I'd rather call it a list of principles. Reminds me of (unfortunaltely out of
print):

[http://www.amazon.com/Principles-Software-Development-
Alan-D...](http://www.amazon.com/Principles-Software-Development-Alan-
Davis/dp/0070158401)

------
rosser
As a database guy working in a Rails shop, I have huge qualms with "DRY". It
encourages people to encode relationships in their models, and trust that's
somehow magically going to keep their data sane. It's not. Believe me, it's
not.

If you're using an RDBMS, _use it_. The model is just a representation of the
data's canonical, authoritative state, which is what it looks like when it's
been committed to the DB. The only way to keep your data sane is with Foreign
Keys enforcing referential integrity between tables, and the only way to do
that is to specify the relationship in both your models, _and_ in your
migrations.

Blind, slavish adherence to a pithy acronym is just going to get you into
trouble.

~~~
jemfinch
The entire concept of database normalization is just a manifestation of DRY.
Foreign keys _exist_ so you don't repeat yourself by duplicating the same data
in two databases.

~~~
Silhouette
Interesting parallel, but I'm not sure it's a good analogy with the typical
DRY advice for writing code. In the real world, database normalization isn't
automatically the right answer, and there can be valid reasons for repeating
yourself.

Then again, there can be valid reasons for repeating yourself when writing
code as well. Personally, I prefer "don't repeat yourself without a clear
reason for doing so", which is a very different guideline.

~~~
jemfinch
"Don't repeat yourself without a clear reason for doing so" isn't really
different at all from what most people mean when they say, "DRY". It's just
removed from the ultra-literalistic interpretive context that too many
Internet commentators apply to admonitions and guidelines of all sorts.

No developer who says, "DRY" actually means, "Never, ever repeat yourself." No
developer who offers advice of any kind expects that it applies under all
circumstances. We still phrase it in strict, prescriptive terms because it
retains more of its moral force that way.

Anyone who expects pithy development advice to note exceptions is interpreting
it in a juvenile way.

~~~
Silhouette
I'm afraid our experience is very different. I find the programming world to
be full of people who will interpret guidelines like DRY with almost religious
dogmatism, particularly if anyone Internet famous can be cited as the source.

Having been a mentor to many younger and less experienced programmers when
they started working professionally, I have been the guy who had to clear up
their absolute, literal belief in these sayings. Some people will quickly
understand and accept that the world isn't as black and white as perhaps their
CS course/favourite blogger/previous boss said or that they have taken rules
of thumb too literally. Some never really do understand that, and their code
reflects their lack of understanding and often looks like it was written to
comply with every saying under the sun as its primary goal.

------
ctdonath
One quibble: "DRY?" isn't meaningful to anyone not exposed to that non-
ubiquitous acronym. If I stick this sheet outside my cube I'll be explaining
it over and over, or (worse) the curious and otherwise open-minded will walk
off dissuaded by opacity.

~~~
MBlume
I would be a little bit afraid of working in a technical shop where "DRY"
wasn't ubiquitous.

~~~
hermanhermitage
Yes but some shops wont know it under that name.

Its common nomenclature in the scripting and web space, but less so in other
areas.

It was called design normalization and factorization when I was introduced to
it in the early 80s.

~~~
MBlume
Ooh. TIL.

------
priyanka_sri
Beginning with such a simplified list proves useful. I would say the first
point has to be "Are there 'existing' solutions to this (Architecture)
Problem? If yes, what are they & what are their pros & cons?" It always
surprises me (& I learnt from a wise man & my mentor) that you aren't the
first one (& almost never alone) when you encounter any problem.

~~~
ilija139
I liked this so much that I created a live Google Doc document to be filled
with questions like this.
[https://docs.google.com/document/d/1u9cxtuYQQ0XENgSSyy3OGBS2...](https://docs.google.com/document/d/1u9cxtuYQQ0XENgSSyy3OGBS2EaoyPBF7Y_P4GxMJvIU/edit)

I added your comment, I hope it's OK.

------
nonrecursive
Here's a good taxonomy of software quality attributes, which are strongly
related to architecture:
<http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm>

------
ctdonath
Curious abuse of fonts. The "g" displayed is "!" in other fonts, hindering
copying (I'd print it as-is, but the "DRY" acronym is unnecessary &
confusing).

------
ExpiredLink
Why are these rules "software architecture" specific?

~~~
btilly
People don't normally try to rearchitect their personal homes into skyscrapers
while they are living in them. But as a software company scales, people face
the morally equivalent problem in software all of the time.

That fact makes the key design principles different. Fully a third of the
bullet points on this cheatsheet speak directly to the needs of making that
kind of change later.

------
chrisohara
YAGNI should be on there

~~~
danparsonson
That's item 1 on his list isn't it?

