System Architecture - a bell curve based journey

If programming is a gymnastics team sport, then architecture is the balance beam. One slip and the team is paralysed.

Balancing is an act of doing, learning, observing and taking feedback. When you’re trying to balance, what your eyes see and what your body feels does not mean the observer sees the same.

A Bell Curve

Picking up technical debt early on a project can be debilitating, but also overthinking things can lead to the same. If you’re not moving forwards then you are in fact moving backwards. Consumer user patterns change all the time and competitive landscapes can accelerate the change by merely trying to unseat customer loyalties.

The process of finding the centre of the bell curve is ongoing and requires continuous exercise of an OODA loop, taking into account the project constraints and requirements. That might be support, pricing, profit or skill set as well as required progress.

There is no case here for lumping this information into adversary arguments. Technology writers and media outlets love the heads and tails approach to IT. Make a statement and fight the case. This isn’t that and despite this appearing to be common sense, will remain uncontroversial.

Only learning, observation, question-asking and curiosity will help you climb that lovely bell peak!

It’s something I battle with and exercised daily. When pressure is high, it’s far too easy to go after outcomes mindlessly in the name of ‘fail fast’. Knowing you’re going to fail ahead of time isn’t failing fast, it’s foolhardy. Getting stuck into a problem because its fun when we have objectives to deliver is also the same. Push the boundary to the point of discomfort and ask the ‘why’ questions.

• Tags: software architecture
• Categories: software architecture