Avoid accidental complexity, and 96 other things every software architect should know

Favor simplicity. Avoid accidental complexity. Don't worry about building the 'perfect' beast. Don't worry about future-proofing. Treat people with respect.

These common-sense pearls of wisdom come from a book titled 97 Things Every Software Architect Should Know, edited by Richard Monson-Haefel, that is packed with truisms by dozens of authorities for managing technology solutions in the context of today's business environments. Thanks to David Chappell (.NET guru) for surfacing this book, originally published last summer, on his must-read list.

Here are 10 select gems pulled from the list of 97:

Chances are your biggest problem isn't technical (by Mark Ramm): "Mere familiarity with the conversation as a technology isn't enough.  Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into an effective architect."

Don't put your resume ahead of the requirements (by Nitin Borwankar): "Always put the customer's long-term needs ahead of your own short term needs and you won't go wrong."

Simplify essential complexity; diminish accidental complexity (by Neal Ford): "Prefer frameworks derived from working code rather than ones cast down from ivory towers. Look at the percentage of code you have in a solution that directly addresses the business problem vs. code that merely services the boundary between the application and the users. Cast a wary eye on vendor-driven solutions... vendors often push accidental complexity. Make sure that the solution fits the problem."

Simplicity before generality, use before reuse (by Kevlin Henney): "Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality."

Reuse is about people and education, not just architecture (by Jeremy Meyer): "If your team doesn’t know where to find reusable artifacts or how to reuse them they will default to the natural, human position: they will build it themselves. And you will pay for it."

Control the data, not just the code (by Chad LaVigne): "Database changes shouldn’t create a ripple in your build’s time-space continuum.  You need to be able to build the entire application, including the database, as one unit.  Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends."

'Good Enough' is good enough(by Greg Nyberg): "Don't give in to the temptation to make your design, or your implementation, perfect! Aim for 'good enough' and stop when you've achieved it."

Make a strong business case (by Yi Zhou): "Most people believe in “perception is reality.” Therefore, if you can control how people perceive the architectural approach you propose, it’s virtually guaranteed that you control how they will react to your proposal. How can you mange stakeholders’ perceptions? Make a strong business case for your architecture. People who have the budget authority to sponsor your ideas are almost always business-driven."

Software doesn’t really exist(by Chad LaVigne): "Remember that a requirements document is not a blueprint and software doesn’t really exist.  The virtual objects that we create are easier to change than their physical world counterparts, which is a good thing because many times they’re required to.  It’s ok to plan as though we’re building an immovable object; we just can't be surprised or unprepared when we’re asked to move said object."

You can't future-proof solutions(by Richard Monson-Haefel): "It’s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. In short, today’s solution will always be tomorrow’s problem"