Category: Software Architect

A disappointing trend has been in bloom for some time now within software development; the attempt to professionalize the practice of software architecture as one on par with the classical school of Architecture. This seems to stem from some need for further legitimization of one’s accomplishment beyond acknowledgment among one’s peers and employer. By comparison, Architecture itself was not professionalized until the late 19th century, at least a few millennia after the practice had been around. It would be no great stretch to say that some software architects seem a bit eager by comparison.

Software architecture is a craft, and it certainly takes practice and discipline to achieve success in the field. That said, software development is still a relatively nascent endeavor. We don’t even know enough about this practice to adequately professionalize it. Despite its youth, software development’s product has become a highly valued tool, and as such, the accomplished individuals (as well as those who wish to be seen as accomplished) have enjoyed levels of compensation on par with the leading professional fields, including medicine, accounting, and law.

Practitioners of software development enjoy considerable compensation for work that is highly creative and exploratory. The fruits of our labors have been used to accomplish many significant milestones, some that benefit all of mankind. The barriers to entry are largely one’s own merit and opportunity; the fully-professionalized fields undergo programs of study and internship that dwarf our own. Dwell on that for a moment and ponder how much cause we have to be content, and just how brash it is to insist that software architect be considered a title that sits as peer to Lawyer, Doctor, and Architect.

The title of software architect has only lower-case ‘a’s; deal with it.

I’ve worked on hundreds of software projects. Every one had issues that caused more problems than the team expected. Often, a small part of the team identified the issue early on and the majority dismissed or ignored it because they didn’t understand how important it really was until it was too late.forces at work include:

The forces at work include:

• Issues that seemed trivial early in the project become critical after it is too late to fix them. While the boiling frog experiment may be folk-lore, it’s a useful analogy for what happens in many projects.
• Individuals often face resistance when the rest of the team does not share their experience or knowledge. Overcoming this resistance requires unusual courage, confidence and persuasiveness. It rarely happens, even with highly paid, experienced consultants specifically hired to help avoid such problems.
• Most software developers are optimists. Painful experience teaches us to temper our optimism, but without specific experience we tend toward optimism. Natural pessimists on development teams are often unpopular, even if they are consistently right. Few people will risk this reputation and take a stand against the majority without a very solid case. Most of us have had the “This makes me uncomfortable, but I can’t explain why” feeling, but sharing it rarely wins any arguments.
• Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
• We all have blind spots; short-comings that are difficult for us to recognize or to accept.

Some possible strategies to counter-act these forces could include:

• Establish an organized approach to managing risks. One simple approach is to track risks the same way you track bugs. Any one can identify a risk and each risk is tracked until it is no longer a risk. Risks are prioritized and reviewed when their status changes or when there is new information. This helps remove emotion from the discussion and makes it easier to remember to re-evaluate them periodically.
• When going against the majority, look for ways to help the rest of the team understand more easily. Encourage any team you’re on to recognize the value in dissenting opinions and look for neutral ways to discuss them.
• “Bad smells” are worth recognizing. If the facts aren’t there yet, look for the simplest tests that would provide the facts.
• Constantly test your understanding against the team and the customer. Tools such as a prioritized list of user stories can help but are no substitute for regular communications with the customer and an open mind.
• Blind spots are, by definition, hard to recognize. People you trust to tell you the hard truth when you need it are a precious resource.