7 ms·

Software architecture cheat sheet

287 points by grayprog 14y ago

priyanka_sri 14y ago
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 14y ago
  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/1u9cxtuYQQ0XENgSSyy3OGBS2EaoyPBF7Y_P4GxMJvIU/edit https://docs.google.com/document/d/1u9cxtuYQQ0XENgSSyy3OGBS2... I added your comment, I hope it's OK.
ExpiredLink 14y ago
Why are these rules "software architecture" specific?
- bduerst 14y ago
  It should be "Problem Solving Cheat Sheet". It should also include >Bias: Is this an agnostic solution? Am I or anyone else too invested in it?
- ctdonath 14y ago
  All points certainly apply in all forms of architecture, but some points are more pronounced for particular forms. Even if depicted the same and having the same gravitas, the manifestation of the point varies. Testing, for example, is obviously paramount in architecting buildings because failures can be horribly expensive and lethal ... but software development is too often prone toward "happy path testing". Repeating is more problematic in software thanks to Ctrl-C / Ctrl-V, whereas other disciplines have nontrivial time & cost sunk in doing something more than once. Cost of changes is profoundly different. Since building software is nigh unto free (click "build", wait seconds or minutes) instead of costly (bridges take months or years), those involved are too often seduced by the notion that changes cost nothing.
- btilly 14y ago
  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.
- acg 14y ago
  I'd go further than this, if this is confusing architecture with development. This is not to say that a senior developer or systems engineer could take on an architecture role: but this wouldn't be the check-list in my view. An architect is more likely, like his building counterpart, to see the system from the top down. That is given a clean sheet of paper: How can we achieve the availablility and fault-tolerance we need? what is the threading model? how does the system connect to the outside world? etc... Whoever takes the role of doing this makes sure that the direction of the implementation doesn't loose sight of these goals. He may even create non-functional requirements.
ChuckMcM 14y ago
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 14y ago
  What's your solution to the bathroom problem?
  - cbhl 14y ago
    You build a large bathroom closer to the banquet hall. :)
  - jerf 14y ago
    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.)
ctdonath 14y ago
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 14y ago
  I would be a little bit afraid of working in a technical shop where "DRY" wasn't ubiquitous.
  - hermanhermitage 14y ago
    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 14y ago
      Ooh. TIL.
- mcantor 14y ago
  I'll be explaining it over and over An ironic plight.
ctdonath 14y ago
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).
deleted 14y ago
[deleted]
RyanMcGreal 14y ago
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 http://gawande.com/the-checklist-manifesto
- jonsen 14y ago
  I'd rather call it a list of principles. Reminds me of (unfortunaltely out of print): http://www.amazon.com/Principles-Software-Development-Alan-Davis/dp/0070158401 http://www.amazon.com/Principles-Software-Development-Alan-D...
nonrecursive 14y ago
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 http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm
rosser 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      "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.
chrisohara 14y ago
YAGNI should be on there
- danparsonson 14y ago
  That's item 1 on his list isn't it?

287 points by grayprog 14y ago

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 14y ago
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/1u9cxtuYQQ0XENgSSyy3OGBS2EaoyPBF7Y_P4GxMJvIU/edit https://docs.google.com/document/d/1u9cxtuYQQ0XENgSSyy3OGBS2... I added your comment, I hope it's OK.

ExpiredLink 14y ago

Why are these rules "software architecture" specific?

bduerst 14y ago
It should be "Problem Solving Cheat Sheet". It should also include >Bias: Is this an agnostic solution? Am I or anyone else too invested in it?
ctdonath 14y ago
All points certainly apply in all forms of architecture, but some points are more pronounced for particular forms. Even if depicted the same and having the same gravitas, the manifestation of the point varies. Testing, for example, is obviously paramount in architecting buildings because failures can be horribly expensive and lethal ... but software development is too often prone toward "happy path testing". Repeating is more problematic in software thanks to Ctrl-C / Ctrl-V, whereas other disciplines have nontrivial time & cost sunk in doing something more than once. Cost of changes is profoundly different. Since building software is nigh unto free (click "build", wait seconds or minutes) instead of costly (bridges take months or years), those involved are too often seduced by the notion that changes cost nothing.
btilly 14y ago
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.
acg 14y ago
I'd go further than this, if this is confusing architecture with development. This is not to say that a senior developer or systems engineer could take on an architecture role: but this wouldn't be the check-list in my view. An architect is more likely, like his building counterpart, to see the system from the top down. That is given a clean sheet of paper: How can we achieve the availablility and fault-tolerance we need? what is the threading model? how does the system connect to the outside world? etc... Whoever takes the role of doing this makes sure that the direction of the implementation doesn't loose sight of these goals. He may even create non-functional requirements.

ChuckMcM 14y ago

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 14y ago
What's your solution to the bathroom problem?
- cbhl 14y ago
  You build a large bathroom closer to the banquet hall. :)
- jerf 14y ago
  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.)

ctdonath 14y ago

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 14y ago
I would be a little bit afraid of working in a technical shop where "DRY" wasn't ubiquitous.
- hermanhermitage 14y ago
  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 14y ago
    Ooh. TIL.
mcantor 14y ago
I'll be explaining it over and over An ironic plight.

ctdonath 14y ago

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).

deleted 14y ago

[deleted]

RyanMcGreal 14y ago

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 http://gawande.com/the-checklist-manifesto

jonsen 14y ago
I'd rather call it a list of principles. Reminds me of (unfortunaltely out of print): http://www.amazon.com/Principles-Software-Development-Alan-Davis/dp/0070158401 http://www.amazon.com/Principles-Software-Development-Alan-D...

nonrecursive 14y ago

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 http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm

rosser 14y ago

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 14y ago
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 14y ago
  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 14y ago
    "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.

chrisohara 14y ago

YAGNI should be on there

danparsonson 14y ago
That's item 1 on his list isn't it?