97 Things Every Software Architect Should Know – 27/97

I know, there really is an ‘i’ in architecture. But it‘s not a capital ‘I’, calling attention to itself, dominating discussion. The lower-case character fits neatly within the word. Its there only because it fulfills requirements for proper spelling and pronunciation.

How does that relate to us as software architects? Our egos can be our own worst enemy. Who hasn‘t experienced architects who:

• Think they understand the requirements better than the customers.
• View developers as resources hired to implement their ideas.
• Get defensive when their ideas are challenged or ignore the ideas of others.

I suspect any experienced architect has fallen into at least one of these traps at some point. I‘ve fallen into all of them and learned painful lessons from my mistakes.

Why does this happen?

• We‘ve had success – Success and experience build self-confidence and allow us to become architects. Success leads to bigger projects. There is a fine line between self-confidence and arrogance. At some point the project is bigger than our personal ability. Arrogance sneaks in when we cross that line but don‘t know it yet.
• People respect us – Tough design questions provide a critical safety net. Our own defensiveness, arrogance, or emphasis on our experience can result in missed design questions.
• We‘re human – Architects pour themselves into each design. Criticism of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.

How do we avoid it?

• Requirements don‘t lie – With correct, complete requirements, any architecture that meets them is a good one. Work closely with the customer to make sure you both understand the business value each requirement provides. You don‘t drive the architecture, the requirements do. You do your best to serve their needs.
• Focus on the team –These are not just resources; they are your design collaborators and your safety net. People who feel unappreciated usually make a poor safety net. It‘s the teams‘ architecture, not yours alone. You provide guidance but everyone does the heavy lifting together. You need their help as much or more than they need yours.
• Check your work – The model is not the architecture. It is only your understanding of how the architecture should work. Work with your team to identify tests that demonstrate how the project‘s architecture supports each requirement.
• Watch yourself – Most of us fight our natural tendencies to defend our work, focus on our selfish interests, and see ourselves as the smartest person in the room. Pressure pushes these tendencies to the surface. Consider your interactions for a few minutes every day. Did you give everyone‘s ideas the respect and acknowledgement they deserved? Did you react negatively to well meaning input? Do you really understand why someone disagreed with your approach?

Removing the ‘I’ from architecture doesn‘t guarantee success. It just removes a common source of failure that‘s entirely your fault.

97 Things Every Software Architect Should Know – 26/97

You might adopt the approach that a framework that is well designed, or an architecture that is carefully considered, and cleverly implemented will lend itself to re-use within your organization. The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who:
a) know it is there
b) know how to use it
c) are convinced that it is better than doing it themselves

a) Know its there

Within your organization, developers or designers need to know a design, framework, library, or fragments of code exists and where they can find all the critical information about these elements (e.g. documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won’t look for things that they don’t believe to exist. You are more likely to succeed with reusable elements if the information about them is ?”pushed”.

There are any number of methods for pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to e-mail announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or shouting it across the office. Ultimately, whatever your process for communicating about reusable elements… make sure you have one, don‘t leave it up to chance.

b) Know how to use it

Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth‘s terminology) “resonate” with coding and design. We have all worked with them, the gifted developers and architects whose speed and depth of understanding is impressive, even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.

Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the framework designer intended them to use. They need to be given easy access to that information in the form of up-to-date documentation, or even better, training. A little training goes a long way to ensuring that everyone is on the same page when it comes to reuse.

c) Are convinced that its better than doing it themselves

People, and particularly developers, tend to prefer to solve problems themselves rather than ask for help. Asking how something works is a sign of weakness, or even an indication of ignorance. This has a lot to do with the maturity and personality type of your individual team-members, “Better than doing it themselves” means different things to different people. The “young guns” on your team will always want to write things themselves because it appeases their ego, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution.

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.