97 Things Every Software Architect Should Know

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m (Contributions)
m (Contributions)
Line 92: Line 92:
[[Contribution 22]]: "Architects focus is on the boundaries and interfaces" by [[Einar Landre]]
[[Contribution 22]]: "Architects focus is on the boundaries and interfaces" by [[Einar Landre]]
-
[[Contribution 23]]: "Architects must be hands on" by [[John Davies]]
+
[[Contribution 23]]: "Architects must be hands on" by [[User:Jtdavies | John Davies]]
[[Contribution 24]]: "Continuously Integrate" by [[Dave Bartlett]]
[[Contribution 24]]: "Continuously Integrate" by [[Dave Bartlett]]

Revision as of 22:37, 18 May 2008

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.


Contents

What will come of all this?

O'Reilly will eventually publish the contents of this wiki in a public and free web site off of the O'Reilly properties. 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 (perhaps through OpenID) 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 500 and 700 words long. If they are shorter O'Reilly might request that you expand them to 500 words. If they are longer O'Reilly will suggest edits to shorten the entry to 700 words. If the entries are not 500 - 700 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 (kata, sutra, commandment, principle, whatever you prefer to call it) 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 500 and 700 words. Discussions shorter than 500 words are fine, but longer ones are more 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 700 words. We'll want (minimally) a bio, contact info, and a head shot. Only contributions with associated bios (including contact info, 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. Please keep your author page up to date.
  • Please, no illustrations and no code. We want principles of software architecture, not detailed coding examples. 500 - 700 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 works on this site are covered under the Creative Commons Attribution 3 license. 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 0 shows how we want you to structure contributions.

(Right now, I'm just calling these contributions--that will allow us to add a level of indirection when start to assemble the book).

We're looking forward to working with you.

Richard Monson-Haefel, Curl Inc.

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

Contributions

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

Contribution 0: "Today’s solution is tomorrow’s problem" by Richard Monson-Haefel

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

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

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

Contribution 4: "Communication is King" by Mark Richards

Contribution 5: "Architecting is about balancing" by Randy Stafford

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

Contribution 7: "Stand Up!" by Udi Dahan

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

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

Contribution 10: "Quantify" by Keith Braithwaite

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

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

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

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

Contribution 15: "The number of IPCs drives response time" by Randy Stafford

Contribution 16: "Commit-and-run is a serious crime. Respect your colleagues." by Niclas Nilsson

Contribution 17: "Beware answers in search of questions." by Nathaniel Schutta

Contribution 18: "There Can be More than One" by Keith Braithwaite

Contribution 19: "An Architect Stands in the Middle" by Dave Bartlett

Contribution 20: "Business Drives" by Dave Muirhead

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

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

Contribution 23: "Architects must be hands on" by John Davies

Contribution 24: "Continuously Integrate" by Dave Bartlett

Contribution 25: "Sometimes it's better to let the train pass you by" Norman Carnovale

Contribution 26: "Architectural Tradeoffs" by Mark Richards

Contribution 27: "Database as a Fortress" by Dan Chak

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

Contribution 29:

Contribution 30: "Reuse is about people and education, not just architecture" By Jeremy Meyer

Contribution 31:

Contribution 32:

Contribution 33:

Contribution 34:

Contribution 35:

Contribution 36:

Contribution 37:

Contribution 38:

Contribution 39:

Contribution 40:

Contribution 41:

Contribution 42:

Contribution 43:

Contribution 44:

Contribution 45:

Contribution 46:

Contribution 47:

Contribution 48:

Contribution 49:

Contribution 50:

Contribution 51:

Contribution 52:

Contribution 53:

Contribution 54:

Contribution 55:

Contribution 56:

Contribution 57:

Contribution 58:

Contribution 59:

Contribution 60:

Contribution 61:

Contribution 62:

Contribution 63:

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