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.
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.)
Ideally the architect is looking at a 'proposed' plan rather than what got implemented.
There is an entirely different (and very valuable) class of folks to can take an existing screw up and map out a series of steps to un-screw it up [1]. :-)
[1] I used to watch the New Yankee Workshop on PBS and see Norm cut lumber and then have it fit together so closely and smoothly that it practically didn't need glue. I suggested to my wife we could make a TV show which explored creative uses for a 2 x 4 that was 1/2" too short for its original purpose, or other parts that were made scrap by an imprecise execution of the 'cut to size' phase.
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.
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.
The DRY ideal in this case would be more about describing the relationship only once, and having that relationship then propagate everywhere it needs to, most especially to the foreign keys in your database schema.
Sometimes, reaching that ideal is not practical and in the name of pragmatism a programmer will indeed repeat themselves. But that repetition is where the trouble starts. If you have to describe a relationship twice, then sooner or later someone is going to forget to update one place or the other. As a database guy, you would like them to always remember to update the place that tells the database about that relationship. But in reality, it may be just as likely that someone will update the model and forget to update the database.
The idea with DRY is that you should try very hard to find a way to represent the relationship only once so that mistakes can't happen, but that doesn't mean sacrificing the integrity of your data to do so.
That said, I know little about Rails, and perhaps it's hard to do it right, or at least easy to do it wrong.
Wait a sec, just because someone misused a term like "DRY" doesn't mean the principle is wrong. Re-representing data models in other execution environments is indeed a repetition - it just normally isn't identified as one, for some reason.
Adding a database field often has repercussions throughout the stack (not to mention throughout the rest of the system).
What's really interesting is to realize that DRY is traditionally only applied to static code, rather than runtime state. But personally I think it should apply to both.
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.
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.
"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.
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.
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.
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.
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).
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.
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.
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.
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.