Chances are your biggest problem isn’t technical

97 Things Every Software Architect Should Know – 3/97

Right now someone’s running a failing project to build a payroll system. Probably more than one someone.

Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We’ve all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn’t up the the task?

Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about what it takes to help make those people successful.

Equally, there’s a good chance that there’s someone who you think is “just not doing it right” and is undermining the project. In these cases, the technology you need to solve your problem is very old and well established indeed, in fact it’s possibly the most important technical innovation in the history of humanity. What you need is a conversation.

Mere familiarity with the conversation as a technology isn’t enough. Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into one an effective architect.

There’s lots more to it than this, but a couple small tips can significantly increase your conversational effectiveness:

1) Approach these events as conversations — not as confrontations.

If you assume the best about people and treat this as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive.

2) Approach these conversations only after you’ve got your attitude right.

If you’re angry, frustrated, annoyed, or otherwise flustered its very likely that the other person will interpret you non-verbals as indicating that you’re on the attack.

3) Use these as opportunities to set mutually agreed upon goals.

Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people’s participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.

If you start with a shared purpose, treat people “problems” as an opportunity to learn, and manage your own emotions, you’ll not only become more effective, you’ll also discover that you learn something every time.

'Coz sharing is caring

Simplify essential complexity; diminish accidental complexity

97 Things Every Software Architect Should Know – 2/97

Essential complexity represents the difficulty inherent in any problem. For example, coordinating a nation‘s air traffic is an inherently complex problem. Every plane‘s exact position (including altitude), speed, direction and destination must be tracked in real time to prevent mid air and runway collisions. The flight schedules of aircraft must be managed to avoid airport congestion in a continuously changing environment – a sever change in weather throws the entire schedule out of whack.

Conversely, accidental complexity grows from the things we feel we must build to mitigate essential complexity. The antiquated air traffic control system used today is an example of accidental complexity. It was designed to address the essential complexity of controlling the traffic of thousands of airplanes, but the solution itself introduces it‘s own complexity. In fact, the air traffic control system used today is so complex that updating it has proven to be difficult if not impossible. In much of the world air traffic is guided by technology that is more than 30 years old.

Many frameworks and vendor “solutions” are the symptoms of the accidental complexity disease. Frameworks that solve specific problems are useful. Over-engineered frameworks add more complexity than they relieve.

Developers are drawn to complexity like moths to flame, frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn’t like the rush of solving some incredibly complex problem? In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging.

How do you do this? Prefer frameworks derived from working code rather than ones cast down from ivory towers. Look at the percentage of code you have in a solution that directly addresses the business problem vs. code that merely services the boundary between the application and the users. Cast a wary eye on vendor driven solutions. They may not be inherently bad, but vendors often push accidental complexity. Make sure that the solution fits the problem.

It‘s the duty of the architect to solve the problems inherent in essential complexity without introducing accidental complexity.

'Coz sharing is caring