Sanity Architect

The Inmates Are Running the Asylum

Alan Cooper takes a stab at trying to explain why so much of our technology seems 'insane' by offering anecdotes of technology failures we all instantly empathize with as frustrating.

Why are VCRs impossible to program? Why do car alarms make us all crazy at all the wrong times? Why do our computers reprimand us when they screw up? All of these computerized devices are wildly sophisticated and powerful, and they have proliferated our desks, our cars, our homes and our offices. So why are they still so dauntingly complicated to use?

Ironically, building computerized products isn't difficult, they only seem so because our process for making them is out of date. To compound the problem, the costs of badly designed software are incalculable, robbing us of time, customer loyalty, competitive advantage and opportunity.  

"He believes that in part, the problem lies in the fact that business executives in the high-tech industry have relinquished their control to the engineers and techies. In the rush to accept the many benefits of the silicon chip, responsibility has been abandoned, and "the inmates have been allowed to run the asylum." The solution, Cooper says, is to harness those talents to create products that will both thrill their users and grow the bottom line"

While I believe Cooper has provided us with some really valuable insight, I have to disagree with him on this last point somewhat. It is mythful thinking to believe that somehow "business executives in the high-tech industry have relinquished their control to the engineers and techies" and while this may be correct in some cases, sometimes exactly the opposite is the problem, sometimes engineers and techies have relinquished their control to team leads, managers, and business executives.

It is not hard to realize that often CEOs and techies have different perspectives, and consequently often have trouble communicating or making good decisions, either alone or in cooperation.

Software Sanity Architect

CEO's and Techies need a mediator; and while generally that mediator would be the Software Architect, we have had Software Architects for decades and still there is still an incredible amount of insanity in the software development enterprise, usually resulting in driving the end users of software technology insane.

Polymath in the Job Description

To some degree all Architects need to be polymaths, but the Sanity Architect more so, with special emphasis on

• Psychology
• Political Science
• Anthropology

Basically the Sanity Architect fulfills two important roles, among other things

1. Analyst - in the sense of psychology, political science and anthropology, in addition to all the other technical stuff.
2. Therapist - in the sense of psychology, political science and anthropology, but also in the sense of software development methodology, processes and best practices.

Pathological Examples

Muda

In the automobile industry, the Japanese realized long ago that if your factory floor is covered in litter, grease and oil; that if tools are not put away when not used any more; that if your inventory is full of stuff you are never going to use or sell; then productivity and safety are going to be compromised. What some companies do is they have a "muda day" a few times a year where production stops and everyone just cleans up the mess, so production can start again on a clean safe foundation.

In the software industry there is no visible factory floor, most of the production goes on in the minds of the software developers and bits flowing through computer systems and networks. When the CEO walks in to a techie's office, the techie may have a clean or a messy office, but the CEO has no real way to appreciate at a glance how much muda there is under the surface of it all, and in almost all cases the CEO has never considered that muda applies to software development too.

One duty of the Sanity Architect is to realize muda is a problem, sit down with the CEO, the technies, and all people who are stakeholders in the software enterprise and explain the problem in terms they can all understand - that muda is undermining productivity and safety, is decreasing Return on Investment and increasing Total Cost of Ownership.

Refactoring

Code refactoring can be a controversial subject. While some team leads, managers and executives support the idea, there are startling numbers who do not. Often if a lowly code monkey wants to spend some time refactoring code they cannot get permission, or if they do so without permission they get reprimanded.

Sadly the result of insufficient code refactoring is more muda. The productivity of the code monkeys drops, and management responds by complaining about the software development team, demanding they work harder, or by off-shoring software development to a cheaper labor force.

Another duty of the Sanity Architect is find specific examples of muda, such as messy unmaintainable code, how much that is costing the business, and how everyone can profit by applying the correct amount of code factoring. In addition showing everyone that there are best practices around this that can be supported with methodology and process improvement the Sanity Architect also has to be a:

• Psychologist who can diagnose the organizational and human dynamics that led to the insanity, and then prescribe and administer the necessary therapy.
• Political Scientist who can analyze if there is too much politics that led to the insanity, and then act as an ambassador to prescribe and administer the necessary diplomacy.
• Anthropologist who can research the deeper issues and identify latent causes to the insanity, and then act as philosopher to prescribe and administer the needed insight and opportunities for innovation.

Influence

In his presentation, Dan Pink makes the case that only 10% of the population are recognized as being in sales, but that the other 90% are are also involved in sales every day, every time we have to sell our ideas or positions to another person. He offers three key qualities in being successful in selling:

1. Attunement - being attuned to the perspectives of others
2. Buoyancy - staying afloat in a sea of rejection
3. Clarity - articulating your message as clearly as possible attuned to the perspective of who you are selling to; defining problems your listener never knew they had.

Dan cites numerous studies that show a strong correlation to how much power a person has, or believes they have, and how attune they are to other people's perspectives. Largely, the more power someone has, or believes they have, the less attune they are to other people's perspectives - they simply don't care. The less power someone has, or believes they have, the more attune they are to other people's perspective. Ultimately those without power are most attune of all - because they have to be.

When I worked at Motorola they spent a large amount of time and money giving us 'Influence Training' - they cited that autocratic decision making does not lead to quality innovation. Basically influence relied on consensus decisions where everyone was equal in power and contributed by selling their knowledge and ideas to the decision making process. In particular, I was a member of the Process Improvement Process Committee :-)

More than anyone, the Sanity Architect has a duty to define problems the enterprise never knew they had. If they are successful then everyone will realize they all have the same duty, and the enterprise can run a successful process improvement process. Not having a successful process improvement process is a guarantee of insanity.

Finding Software Sanity Architects

OK, I just invented the term 'Software Sanity Architect' so it is not a recognized discipline yet. But as in Field of Dreams "if you build it, they will come" so in the software culture 'if you define it, they will come.'