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

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

Summary: Favor simplicity. Avoid accidental complexity. Don't worry about building the 'perfect' beast.

TOPICS: Software

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"

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • My thoughts

    "Control the data, not just the code"

    I think I'll add that you should know when to use a database and when to just use a basic data structure. Not everything needs a database, and in line with the "Simplicity before generality, use before reuse" principle you just stated, sometimes a database is overkill if you need simplicity.

    "'Good Enough' is good enough"

    Yes and no. No, you shouldn't keep delaying a release just because of a few minor bugs. Yes, you should be aware of whether or not you are expected to perform bug fixes and maintenance releases in the future.

    "You can?t future-proof solutions"


    "Simplicity before generality, use before reuse"

    Agreed, and I've pretty much learned this the hard way. Generality sounds nice in principle, but is extremely difficult to implement in practice.

    It's harder to see all of the edge cases when you can use any sort of data, and it requires a lot more code because you are using indirect methods of access (more pointers/references). In addition, the indirect accesses often make the code slower as well.

    Keep it Simple and Straightforward.
  • Gotta Disagree on one point

    "Simplicity before generality, use before reuse"

    This is a delicate balancing act. Yes, simplicity is a key goal, but generality in the long run is your friend, not your enemy.

    Every time I submit to pressure and create a solution "for just this one little thing" that is *not* general it comes back to bite me in the butt, sually within 6 months.

    General solutions that are also simple are harder to create--but they beat the tar out of a simple solution that (when requirements inevitably change) has to be ripped out and replaced with a general solution.

    Every time I'm assured "this is set in concrete, it'll never change" it changes.

    My advice, yes, keep it simple, but also keep it general!
    • Yep the Middle Path

      I agree with you, there is a balancing act that must be maintained. While I agree with the general tone of the article about keeping it simple, I fear that is going to be taken to literally.

      There is a middle path which balances over engineering with under engineering a solution. To far one way or the other causes issues. To many "one off" under engineered solutions generally lead to a very brittle and ultimately complex architecture which was the goal to avoid in the first place.