Categories
Software Architect

Warning, problems in mirror may be larger than they appear

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.
'Coz sharing is caring
Categories
Software Architect

Value stewardship over showmanship

When an architect enters a project, there is an understandable desire to prove one’s worth. Being assigned the role of software architect typically indicates implicit trust on the part of the company in architect’s technical leadership, and it only follows that the architect would desire to make good on that expectation as soon as possible. Unfortunately, there are those who labor under the misapprehension that proving one’s worth consists of showmanship; bedazzling if not baffling the team with one’s technical brilliance.

Showmanship, the act of appealing to your audience, is important in marketing, but it’s counter productive to leading a software development project. Architects must win the respect of their team by providing solid leadership and by truly understanding the technical and business domain in which they are expected to operate.

Stewardship, taking responsibility and care of another‘s property, is the appropriate role of an architect. An architect must act in the best interests of their customer and not pander to the needs of their own ego.

Software architecture is about serving the needs of one’s customers, typically through direction from those with domain expertise that surpasses one’s own. Pursuing successful software development will lead one to create solutions of compromise, balancing the cost and complexity of implementation against the time and effort available to a project. That time and effort are the resources of the company, which the software architect must steward without self-serving undercurrents. Unduly complex systems that sport the latest hot framework or technology buzzword seldom do so without some sacrifice at the company’s expense. Much like an investment broker, the architect is being allowed to play with their client’s money, based on the premise that their activity will yield an acceptable return on investment.

Value stewardship over showmanship; never forget that you are playing with other peoples’ money.

'Coz sharing is caring