97 Things Every Software Architect Should Know

From WikiContent

Revision as of 06:38, 13 July 2008 by Rmonson (Talk | contribs)
Jump to: navigation, search

Create an Account by clicking create_account. You don't need an email invite to create an account.

This is the (provisional) home page for developing 97 Things Every Software Architect Should Know.

Note: Before the site is made public we will be moving it from a wiki to a much more polished presentation created by professional web designers - this wiki is only an interim solution.

97 Things is a book of wisdom collected from leading software architects. When we have a suitable number of things, we'll open it to the public for comment. When we've reached some still-undetermined magic number, we'll publish it as a book. Right now, 97 sounds good.


What will come of all this?

O'Reilly will publish the contents of this wiki in a public and free web site off of the O'Reilly properties on July 15th, 2008. It will be embodied in a framework that is somewhat like a wiki, anyone can contribute, but looks more professional. It will be free to everyone but you'll have to register to contribute or comment or vote. Users (that's everyone who is registered) will be able to comment on other peoples axioms, rate other people's axioms, tag axioms, and create, edit and improve their own axioms. Anyone and everyone be able to view the material without requiring registration. The web site will be strongly promoted by O'Reilly and all contributers will get full attribution.

From the 97 Things web site O'Reilly plans to pick the top contributions and create a pocket guide which it will sell in bookstores and on-line. If your contribution is chosen any edits recommended by O'Reilly will be contributed back to the 97 Things web site for everyone to enjoy. Only contributions that meet certain requriments will be used in the book. They must be between 250 and 500 words long. The best size is 350 - 500 words. If they are shorter than 250 words O'Reilly might request that you expand them. If they are longer than 500 words O'Reilly will suggest edits to shorten the entry to 500 words. If the entries are not 250 - 500 words long they will not be included in the book, but they will be on the web site. Only works with a full bio will be used in the book. You must include a bio, contact information, and head shot. The contact information will not be in the book unless you want it to be - it will be used by O'Reilly to communicate with authors.

Rules of Engagement

  • Contribution is by invitation only. You can nominate others for inclusion by adding them to the Nominations Page; please make sure to include an email address. We don't yet know whether there's one-to-one mapping between contributors and contributions, but for the time being, assume that each author may write one or more contributions. You can set yourself up with an account (just click create_account) and begin writing your first contribution immediately (see Contribution 0).
  • Each contributor is asked to provide an axiom and a brief discussion. The axiom should only be a 2 to 10 words long if possible. In print, we want each axiom and discussion to fit on a two-page spread. Keep your discussion between 250 and 500 words. Discussions shorter than 250 words are fine, but only ones that are 250 or more are likely to make it into the final book.
  • I'm asking everyone to create an author page (Please create one). Content on your author pages certainly doesn't count towards your 500 words. We'll want (minimally) a bio and a head shot. Only contributions with associated bios (including head shot, and description of background) will be considered for contributions to the book. We may include the bios and head shots in the print version of the book. You may use an icon that's associated with you instead of a picture. Please keep your author page up to date.

For those of us who aren't regular mediawiki users, how is the head shot to be added? To add a head shot, first use the "Upload file" under Toolbox (on the left side) to put the file on the server. Then use a tag like [[Image:filename.jpg]] in the bio.

  • Please also add your snail-mail address and email address to the Addresses page. This information will not be released when the site goes public. We need to keep track of it so that we can send you a comp copy of the print book when it's available, and in case O'Reilly's legal department decides we need to get explicit releases from all the contributors prior to publication. (Hmm. The latter can probably be handled with email.) If you still don't want to disclose your contact info (and I cannot promise that this site won't "leak" out to the rest of the world), please still add your name to Addresses, and write "I'd prefer not to" or something like that. Then send me your contact info.
  • Please, no illustrations and no code. We want principles of software architecture, not detailed coding examples. 250 - 500 well-chosen words can say a lot more than a picture. Please keep contributions product- and technology-agnostic. For example, don't talk about using Java over C#; just talk about principles that are valid across software technologies.
  • Please edit your own contribution only.
  • Please keep this URL private sharing it only with people you invite personally. Don't link to it, digg it, put it on your web pages, send it out to a mailing list, etc. First, it's only temporary. This book will not live within O'Reilly commons indefinitely. Second, we'd like to keep this under wraps until we have a decent block of material to release.
  • All contributions made to this site are required to be made under the Creative Commons Attribution 3.0 license. This means that by making a content contribution, you are agreeing that it is licensed to us and to others under this license. If you do not want your content to be available under this license, you should not contribute it.
  • You warrant that all work that you contribute to this site is your original work, except for material that is in the public domain or for which you have obtained permission.

The Good Stuff

Contribution 21 shows how we want you to structure contributions.

We're looking forward to working with you.

Richard Monson-Haefel, Curl Inc.

Mike Loukides, Editor, O'Reilly Media, Inc.


Please add your contributions here. Go into edit mode for this section to see how to add a new contribution.

Annotations: We are annotating contributions with either "Accepted" which means the axiom as its currently written has been accepted into the book (copy editing pending) or suggested edits. Any contribution that does not say Accepted will need more work in order to be included. We will try to be as explicit about what needs to done as possible. All contributions whether they are Accepted or not will be put on the web site when we go live on July 15th. In other words, Accepted means O'Reilly has chosen that contribution to be in the paper book; all contributions will be on the web site for everyone to enjoy whether they are Accepted or not.

Contribution 1: "Don't put your resume ahead of the requirements" by Nitin Borwankar (Accepted)

Contribution 2: "Simplify essential complexity; diminish accidental complexity." by Neal Ford (Accepted)

Contribution 3: "Chances are your biggest problem isn't technical." by Mark Ramm (Accepted)

Contribution 4: "Communication is King" by Mark Richards (Accepted)

Contribution 5: "Architecting is about balancing" by Randy Stafford (Complete)

Contribution 6: "Always ask for the value to be provided by a requested capability." by Einar Landre (Accepted)

Contribution 7: "Stand Up!" by Udi Dahan (Accepted)

Contribution 8: "Talk about the arch, but see the scaffolding beneath it." by Michael Nygard (Accepted)

Contribution 9: "You're negotiating more often than you think." by Michael Nygard (Accepted)

Contribution 10: "Quantify" by Keith Braithwaite (Accepted)

Contribution 11: "One line of working code is worth 500 of specification." by Allison Randal (Accepted)

Contribution 12: "There is no one-size-fits-all solution" by Randy Stafford (Complete)

Contribution 13: "It's never too early to think about performance and resiliency testing." by Rebecca Parsons (Accepted)

Contribution 14: "Application architecture determines application performance" by Randy Stafford (Accepted)

Contribution 15: "Inter-process communication drives response time" by Randy Stafford (Out-of-bounds. Not an axiom - its too technical)

Contribution 16: "Commit-and-run is a serious crime. Respect your colleagues." by Niclas Nilsson (wrk-in-progress\incomplete profile)

Contribution 17: "Beware answers in search of questions." by Nathaniel Schutta (wrk-in-progress\incomplete profile)

Contribution 18: "There Can be More than One" by Keith Braithwaite '(Accepted)

Contribution 19: "An Architect Stands in the Middle" by Dave Bartlett (wrk-in-progress\incomplete profile)

Contribution 20: "Business Drives" by Dave Muirhead (wrk-in-progress\incomplete profile)

Contribution 21: "Simplicity before generality, use before reuse" by Kevlin Henney (Accepted)

Contribution 22: "Architects focus is on the boundaries and interfaces" by Einar Landre (complete)

Contribution 23: "Architects must be hands on" by John Davies (Excellent, but too short and missing profile)

Contribution 24: "Continuously Integrate" by Dave Bartlett (Very Good, but missing profile)

Contribution 25: "Sometimes it's better to let the train pass you by" Norman Carnovale (wrk-in-progress\incomplete profile)

Contribution 26: "Architectural Tradeoffs" by Mark Richards (Accepted)

Contribution 27: "Database as a Fortress" by Dan Chak (Accepted)

Contribution 28: "Use uncertainty as a driver" by Kevlin Henney (Accepted)

Contribution 29: "Scope is the enemy of success" by Dave Quick (Accepted)

Contribution 30: "Reuse is about people and education, not just architecture" By Jeremy Meyer (Excellent, but 154 words too long and missing profile)

Contribution 31: "There is no 'I' in architecture" by Dave Quick (Accepted)

Contribution 32: "Get the 1000ft view" Erik Doernenburg (Accepted)

Contribution 33: "Try before choosing" Erik Doernenburg (Accepted)

Contribution 34: "Understand The Business Domain" Mark Richards (Accepted)

Contribution 35: "Balance the lifetime of the fields in your objects" Ward Cunningham (wrk-in-progress\incomplete profile)

Contribution 36: "Create new opportunity every iteration." Ward Cunningham (wrk-in-progress\incomplete profile)

Contribution 37: "Look at a problem from as many angles as possible" Rich Kilmer (wrk-in-progress\incomplete profile)

Contribution 38: "Community" Evan Cofsky (wrk-in-progress\missing profile)

Contribution 39: "Applications are for making users as effective as possible" Ben Geyer (wrk-in-progress\incomplete profile)

Contribution 40: "Programming is an act of design" Einar Landre (Accepted)

Contribution 41: "Time changes everything" Philip Nelson (Accepted)

Contribution 42: "Take the hill!" Philip Nelson (Accepted)

Contribution 43: "Value stewardship over showmanship" Barry Hawkins (Excellent but a little too short)

Contribution 44: "If you're unwilling to be hands-on, maybe you should keep your hands off" Barry Hawkins (Accepted)

Contribution 45: "The title of software architect has only lower-case 'a's; deal with it" Barry Hawkins (Accepted)

Contribution 46: "Software architecture has ethical consequences" Michael Nygard (Accepted)

Contribution 47: "Everything will ultimately fail" Michael Nygard (Accepted)

Contribution 48: "Context is King, and Simplicity its Humble Servant" Edward Garson (Excellent, but missing mug shot)

Contribution 49: "It's all about performance" Craig L Russell (Accepted)

Contribution 50: "Never ever break the encapsulation" Einar Landre (Out-of-bounds. Not an IT architecture axiom, but a good OO axiom)

Contribution 51: "Focus on the user interface" Erik Hatcher (wrk-in-progress\missing profile)

Contribution 52: "Apply Systems Engineering practices" Einar Landre (Accepted)

Contribution 53: "Be the Dreamer of Dreams" Evan Cofsky (wrk-in-progress\missing profile)

Contribution 54: "There are no technical problems, only people problems" Donald J. Bales (complete)

Contribution 55: "It is better to be consistently wrong than it is to be inconsistent" Donald J. Bales (complete)

Contribution 56: "The obvious is always illusive" Donald J. Bales (complete)

Contribution 57: "The golden rule: he who has gold rules" Donald J. Bales (short)

Contribution 58: "Engineer in the white spaces" Michael Nygard (Accepted)

Contribution 59: "Talk the Talk" by Mark Richards (Accepted)

Contribution 60: "Heterogeneity Wins" by Edward Garson (Excellent, but missing mug shot)

Contribution 61: "Dwarves, Elves, Wizards, and Kings" Evan Cofsky (Excellent, but missing profile)

Contribution 62: "Lessons From Built Architecture?" Keith Braithwaite (work in progress)

Contribution 63: "Fight repetition" Niclas Nilsson (complete)

Contribution 64:

Contribution 65:

Contribution 66:

Contribution 67:

Contribution 68:

Contribution 69:

Contribution 70:

Contribution 71:

Contribution 72:

Contribution 73:

Contribution 74:

Contribution 75:

Contribution 76:

Contribution 77:

Contribution 78:

Contribution 79:

Contribution 80:

Contribution 81:

Contribution 82:

Contribution 83:

Contribution 84:

Contribution 85:

Contribution 86:

Contribution 87:

Contribution 88:

Contribution 89:

Contribution 90:

Contribution 91:

Contribution 92:

Contribution 93:

Contribution 94:

Contribution 95:

Contribution 96:

Contribution 97:

Contribution N:

Personal tools