The Most Important Question

Posted on by

What’s the most important question for an architect?

complementary opposites

There is a Taoist story of an old farmer who had worked his crops for many years. One day his horse ran away. Upon hearing the news, his neighbors came to visit. “Such bad luck,” they said sympathetically. “May be,” the farmer replied. The next morning the horse returned, bringing with it three other wild horses. “How wonderful,” the neighbors exclaimed. “May be,” replied the old man. The following day, his son tried to ride one of the untamed horses, was thrown, and broke his leg. The neighbors again came to offer their sympathy on his misfortune. “May be,” answered the farmer. The day after, military officials came to the village to draft young men into the army. Seeing that the son’s leg was broken, they passed him by. The neighbors congratulated the farmer on how well things had turned out. “May be,” said the farmer.
(“Maybe” from Zen Stories to Tell Your Neighbors)

The story of the old farmer illustrates an extremely important point for architects: nothing is absolute. There is no universally “right” technique or process. Everything involves trade-offs, where benefits must be weighed against their associated costs. Evaluating those trade-offs and choosing according to the needs of the customer is a key responsibility of an architect.

Dogmatic devotion to some principle or practice leads to being blindsided by reality. In an interview published on Dr. Dobb’s this week, Alan Kay spoke about the importance of questioning beliefs:

The best teacher I had in graduate school spent the whole semester destroying any beliefs we had about computing. He was a real iconoclast. He happened to be a genius, so we took it. At the end of the course, we were free because we didn’t believe in anything. We had to learn everything, but then he destroyed it. He wanted us to understand what had been done, but he didn’t want us to believe in it.

Clinging to mantra’s like “the simplest thing that could possibly work” or “never keep duplicate data” can easily fail you. Caching, for example, violates both of those strictures. Knowing why those guidelines exist is important. Knowing when to violate them is more so.

Likewise, basing design choices on the current fad technology (remember when everything had to be a service?) is unlikely to yield a robust architecture. Worst of all are designs that are implemented because the architect cannot admit that the risks outweigh the benefits. Delivering an unstable or insecure system, just to prove that you can make something “work”, borders on malpractice.

The most important question in architecture is “why”. When questioned about any aspect of the design, if you cannot justify the decision, you should revisit it. Being able to list outcomes, both good and bad, and explain the reasoning behind your choices will garner trust from both customers and colleagues. Most importantly, it should boost your own confidence in the design.

oops

Architect: Someone who knows the difference between that which could be done and that which should be done.
(Larry McVoy’s definition of a Software Architect)

37 thoughts on “The Most Important Question”

  1. Great post, Gene. I like the definition by Larry McVoy — this is exactly what I feel my job is. Although I put it differently: an architect is like a nanny — he/she tells people what not to do. Thanks for the link to the interview, I always try to follow Alan Key, he is definitely an enlightened one, as least as far as software is concerned.

    Like

    Reply

    • Igor, thanks for compliment. I’m fond of McVoy’s definition as well. My co-worker’s have a saying that “with Gene, there’s always a ‘but’.” as in “you can do that, but…”.

      Like

      Reply

    • Thanks! I’ve always believed that being wrong about something is less a problem than being wrong and unable to explain your reasoning for your actions. The latter, in my opinion, implies negligence.

      Like

      Reply

  3. Very profound and practical. But leaving it open has prompted many architects and designers to do things arbitrarily without any reason. A few guiding principles will still be helpful.

    While on this is there a good definition of “architecture”? What I found on SEI site and other sites on Internet are very disappointing. Where has the wisdom gone?

    So, reluctantly I have formulated a definition my self. Would like specialists in architecture to review and give me feedback.

    putchavn@yahoo.com

    Like

    Reply

  5. Pingback: What’s the most important question for an architect? | Software engineering and management | Scoop.it

  7. Hi Gene,

    Liked this post. For an architect, I think “why” is clearly the most important question of all, with “how well” in second, by a length or two. Ackoff’s distinction between analysis and synthesis is so important here. Decomposing a system into its parts can only tell you how they work together, but never why they work that way. To get to why, you have to get to the context that surrounds the system.

    Regards,
    Charlie

    Like

    Reply

    • Charlie,

      I’m very glad you enjoyed the post. Excellent point re: synthesis vs analysis (coincidentally that ties in with an idea for another post that I just queued up).

      I just spent my lunch hour clicking around your blog, lots of great stuff there. Let me add my vote to Ruth Malan’s, please return to posting soon.

      Gene

      Like

      Reply

  8. Pingback: Closing a door « Form Follows Function

  9. This is a really good post, Gene
    Having crossed the line from architecture to agile coaching, I find that asking questions remains my most used tool in my toolbox, and Why remains the most asked question of all.
    You once commented on a post of mine on the role of the agile architect being best equipped to bridge the gap between business and engineering.
    Asking questions generates knowledge sharing across all members of the team, which will promote better architecture.
    After all, the architect does not have all the right answers. But asking the right questions using the knowledge in design and architecture will provoke all team members, business and engineering alike, to criticise the problem and the solution.

    Like

    Reply

    • Thanks, Ilan. Asking questions (and being able to answer them, particularly “why”) is useful across a variety of disciplines.

      By the way, I was reading your Cherry on the Tree blog first thing this morning…the picture of the Asian-style pullets had me ravenously hungry with four hours still to go for lunch!

      Like

      Reply

  10. Good post and I liked this statement – “An acrchitect is someone who knows the difference between what can be done and what should be done”. It tells you everything about it.

    To add – The first most qualification, in my view, of an architect is not finding “solutions” but it is always about finding “questions” hidden in a given problem. Finding solutions is the next step. Definitely ‘Why’ is a good question but there are other forms which bring the characteristics of the problem on to the surface:
    — Who are the users? What are their objectives? What-if an interface changes in future? How does the system (have to) react to different types of user actions? What are the “variables” of present and the variables of “Future” (Maintenance and Extensibility views)?….

    Once you get to this point, it is now working with the technical choices (high-level and low-level OR macro-level and micro-level) for implementing. And yes, a perfect design is never possible and you should never force a “Design Pattern” but rather the design has to be ‘discovered’ with your “questioning” analysis. Your tools might be of no use if you don’t do this. Knowledge of UML like things and CASE tools can’t just make someone an architect. Most of the times, you can get things done without them too. Incidentally, these are the messages I wanted to share in my blog posts as well –

    Discover the Design, Don’t Impose – http://beyondyourcode.blogspot.in/2012/08/discover-design-dont-impose.html

    Once again, thanks for sharing such nice and meaningful statement; sometimes they convey the apt statements very convincingly.

    Like

    Reply

  11. I very much like the quote from Alan Kay. We tend too often to look to pundits to tell us how to think. Civilization is built incrementally, so paying attention to what has been done is important but the past does not define progress into the future.

    BTW: Galloping Gerty was not designed by architects but by civil engineers, arguably the oldest systems engineering profession.

    Like

    Reply

    • As soon as I read the Kay quote, I knew that it would make it into one of my posts. Design involves thought and evaluation, not blindly following a decision tree.

      Re: Gerty – although designed by engineers, it’s such an iconic symbol of failure that it was too tempting to pass up!

      Like

      Reply

  12. Pingback: Reduce, Reuse, Recycle « Form Follows Function

  13. Pingback: Architecting the Process « Form Follows Function

  14. Pingback: The Iron Law of Tools « Form Follows Function

  15. Very astute observations. I agree with everything you’ve said. However, I think it is possible to be *too* pragmatic, sometimes. Usually this is not an architect’s weakness, but it can be. In such cases, the architect doesn’t generalize enough and thus fails to plan for strategic contingencies that are likely to be relevant in the future.

    The “why” question, when answered thoughtfully, is good insurance against this less common failing of software designers, as well as protection against the more common case where pragmatism is given short shrift.

    Like

    Reply

    • Thanks, Daniel. I absolutely agree that failing to account for expected conditions in your design is a problem. Generally I see that as being a matter of inexperience or perhaps slavishly clinging to the “simplest thing that could possibly work” mantra (the opposite of pragmatism).

      Like

      Reply

  16. Pingback: Bumper Sticker Philosophy | Form Follows Function

  17. Pingback: Your Code is not Enough | Form Follows Function

  18. Pingback: There is No “Best” | Form Follows Function

  19. Pingback: Carving it up – Microservices, Monoliths, & Conway’s Law | Form Follows Function

  20. Pingback: Design Follies – ‘It’s all about the technology’ | Form Follows Function

  21. Pingback: Design Follies – ‘Can I’ vs ‘Should I’ | Form Follows Function

  22. Pingback: Bumper Sticker Philosophy | Iasa Global

  23. Pingback: Organizing an Application – Layering, Slicing, or Dicing? | Form Follows Function

  24. Pingback: Are Microservices the Next Big Thing? | Form Follows Function

  25. Pingback: Institutional Amnesia, Cargo Cults and Software Development | Form Follows Function

  26. Pingback: Who Needs Architects? – Monoliths as Systems of Stuff | Form Follows Function

  27. Pingback: The Seventy Million Dollar Question | Form Follows Function

  28. Pingback: Innovation, Intention, Planning and Execution | Form Follows Function

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.