The software architect role seems to be coveted as much by engineers as it is by the teams that work with engineering. There is a core belief that good architecture will help alleviate many future problems and will unlock greater flexibility and speed within the engineering team.

A good software architect can make a big difference to these things, but there seems to be a lot of teams that are hoping to hire a messiah-like figure as their software architect that will hopefully come in and solve all of their problems. While the software architect that is hired is an important hire, the most important thing that leads to good architecture is good planning. You need to know where you are going in order to get there.

Let’s work through a scenario where business stakeholders (or a product team) are describing a new product they would like built, in this case a boat.

Initial product vision:

We’d like to build a boat that can take a couple people fishing

The development team might come back with something like this, which would likely satisfy the requirements and be a good reliable boat for the potential customer:

Iteration 1:

After some feedback from customers some revisions are needed to the boat. Customers are asking for a place to be able to store fish, drinks and food.

The development team works on extending the original design and adds a cooler to the boat:

Iteration 2:

The team says the cooler we just added is not staying cold for long enough. We would like to have a fridge on the boat so we can keep everything cold as long as needed.

The development isn’t sure what ‘long enough’ means but they decide to install a portable battery and a chest fridge to the boat:

Iteration 3:

Our customers have been going out fishing for long days and they need some shade on the boat to keep protected from the sun.

So the development team adds a canopy to the boat. This would add some wind drag at higher speeds but given the size of the boat and the small motor it is unlikely this would be a problem:

Iteration 4:

The days are getting shorter and we need some lights on the boat so if we are still on the water when it’s getting dark then we can see where we are going.

Simple enough for the engineering team to fix, there is a spare plug on the battery to plug in some lights (good architectural decision!)

Iteration 5:

Now we are using the fridge and the lights, the battery we have on the boat is too small and is running out of power. They need power to last all day.

The engineering team has its first bit of tech debt it must deal with. They remove the existing battery and install a larger one with a higher capacity:

Iteration 6:

The boat is not fast enough now that we have added all the additional weight. Can we make it go faster?

The engineering team places a larger outboard motor on the boat which gives the boat a higher top speed. This starts to make the canopy wobble at higher speeds and causes the lights to move around when the canopy moves.

Iteration 7:

Now that we are out on the water all day we need somewhere to go to the bathroom

This is a tall ask, but it’s technically doable…

Iteration 8:

The boat is too small, we need to be able to carry more people

The engineering team gets frustrated by this request. They say things like:

“They should just buy a boat from someone else” and “Would have been nice to know this a little sooner” but it’s an urgent request to keep customers happy. So the solution that is devised came out something like this:

Iteration 9:

We need a place to be able to take a nap when we are out in the boat all day or staying somewhere overnight

After this request a few of the engineers leave the project and go to work for an early stage boat manufacturer where they can be more involved in the planning process from the beginning. The remaining team jerry rigs a solution together to appease the requirement.

At this stage, no one is happy.

The customer starts looking at other options for a product that matches their requirements and was designed to meet those requirements from the start.

The engineering team is requesting to work on tech debt, to rearchitect some fundamental parts of the boat so that it is more flexible for its new use case.

The product team are dealing with a fleeing customer base and any ideas they have to improve the current situation are met with large engineering estimates and less than ideal proposals.

A better path forward

From reading the above (dramatic) example, it might seem like I am making an argument for waterfall style development. While I do like the deliberateness and planning that is required to pull off waterfall style product development, the fast paced competitive landscape, changing customer needs and business demands to get a revenue generating first version to market sooner make this style of development poorly matched to today’s needs.

But slapping together a short sighted MVP and then hoping to iterate from there as you come up with new direction and ideas has significant challenges also

So what is the way forward?

The best way to move fast but also make good architectural decisions is to have an early brainstorming conversations between the product and engineering teams regarding the current roadmap and where it may possibly go in the future. If the engineering team can get a better feel for the direction that the product is going in, they will be more likely to build it in a way that allows it to be flexible where it needs to be and rock solid in its foundation (this is where an architect is helpful).

Here are some generic questions that should be asked in this stage of planning to help make better decisions:

1. Where do you see this product going in 3–5 years?
2. How much throw away work are we creating to just get a first version to market? Is this OK?
3. Is the team on board with the likelihood of reworking key areas of the product if the first version takes off to make it more stable for high customer adoption?
4. What specific decisions are we making now that would severely limit the flexibility to change or extend the product at a later stage?
5. Are there any areas of the product where we can allow for fast paced iteration as an option (usually at the UI layer) while keeping the foundation of the product steady and stable?
6. From an engineering standpoint, are there areas that will likely be replaced in the future? Can these be separated from the core infrastructure to allow for cleaner replacement?

With a bit of foresight, planning and an open conversation about where the product may be heading, teams are able to make good early decisions. These early decisions will set a foundation and direction for the weeks, months and years to come. Don’t confuse speed with velocity. While moving fast is important, getting somewhere is the objective.

The UX Collective donates US$1 for each article we publish. This story contributed to World-Class Designer School: a college-level, tuition-free design school focused on preparing young and talented African designers for the local and international digital product market. Build the design community you believe in.