I spent some time perusing the programming stacks at Seattle’s main library today, and skimmed through some texts on software architecture. Perhaps the most interesting was 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts (ed. Richard Monson-Haefel). It’s a collection of various two-page thoughts from people who do software architecture from across the globe.
Think Chicken Soup for the Software Architect.
Officially, I’ve actually been a software architect and unofficially I’ve done some as the need arose in large clients. I’m not one but I’ve spent the better part of 15 years working with people who are, whether they called themselves this or not.
What I found interesting was how many contradictory pieces of advise that there were.
And how each of them was entirely correct.
This is often the way. Warren Kinston and Jimmy Algie’s decision-making/action languages (now part of Kinston’s Taxonomy of the Human Element in Endeavour) describe seven different approaches that people take when deliberating about action. It’s not about when you just decide to do something, but the approach that you take when you actually have to deliberate. Software architects tend to favor a particular approach, but they (like the rest of us) are represented in every approach.
Which was shown in 97 Things.
People talk about how you need to design upfront properly. Others talk about how you need to just get to work and let things grow organically. Some talk about pilot programs as little models of the larger one. Others talk about them as “develop and throw away”, something like the initial drafting I do as a writer. Some tell how you must get the smartest problem-solvers while another argues that obsessive problem-solving keeps us from getting to the root matter and eliminating the need.
All illustrating an important point: there is no one, single, best way to do software.
If you are a software developer or manage them, you are right now thinking up your response to say how I’m naive and obviously don’t understand software. You will all agree on me being an idiot but you won’t agree on the approach to take. Q.E.D. The best software approach depends on the project, the requirements, the platforms, the other platforms, the programmers, the customers, the support staff — essentially the entire socio-technical situation.
Unfortunately, even if software architects learned this, they would still be battling the Business. Business managers are primarily Pragmatics and look for “low-hanging fruit” even when it will make the project longer or even impossible. This is how Internet Explorer has remained a dominant force in many business web sites even though it is insecure and long-in-the-tooth (it celebrates its tenth birthday in August 2010). Business managers wanted quick solutions but demanded that things work in very particular ways. Software architects hacked together solutions based on IE6’s peculiarities and the companies are now stuck. Pragmatics won’t do an upgrade unless there is a crisis, and they sunk so much money into hobbling together internal IE6-based applications that they can’t get rid of it. One wonders why they can’t encapsulate it via Wine or Crossover Office, but it makes perfect sense to Pragmatic business managers.
Of course, Kinston and Algie’s decision approaches / action languages don’t come into play until we are talking about Human Endeavours. Where people are sill ruled by Monkey Sense — acting like baboons when things go against them — there’s not much that decision languages can do.
Image Credit: Looking down at Château-d’Oex from our chateau on after a snowfall. © E. Forrest Christian.