Mark's Musings

The software architect fallacy

May 10th, 2021
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 2 %ers

September 17th, 2021
This article is about something that I’ve only heard mentioned in Australian Rules Football. From a really early age, when I started playing Australian Rules Football, you would hear the coach repeat over and over again, in practice and before a game about the ‘2 %ers’ (no that’s not URL encoding).

‘Remember the 2 %ers you guys!’, ‘It’s all about the 2 %ers!’, ‘Don’t forget the 2 %ers!’

So what are the 2 %ers? It’s a reference to the small things that players can do during the game that support the team. It’s the stuff that players spend less than 2% of their time doing in the game.

It’s not making a big play or scoring a lot of goals, it’s being vocal on the field so your team mates know that an opponent is about to tackle them, or laying a shepherd (a screen) to keep a defender from tackling your team mate, or running extra hard to the next play to make sure that your team have more players at the ball than the other team.

Every coach I ever had for Australian Rules Football would mention it often, team mates would mention it and my Dad would remind me of it. It was important to not forget about those little things that makes the difference in a game.

Much like an Australian Rules Football team, an Engineering team (or any team within a company) is a made up of players and plays. There are the big plays like shipping a new feature, getting through all the work in a sprint or finding the root cause of a hard to pin down and nasty bug, but there are also the 2 %ers. The small things that individual players do that make the whole team function better.

Within a work team a 2 %er could be:
- Making sure you write an extra clear description for a team member so they aren’t left wondering what you meant.
- Being conscious of the time zone of your co workers and contacting them when they are in their work hours
- Responding to a message to let someone know that you got it.
- Coming prepared to a meeting based on what items in the agenda related to your area.
- Complimenting a co worker when you notice them do something really good.
- Highlighting areas to cut costs on things that are unnecessary but have gone overlooked.
- Sharing credit when there are team members who were really instrumental in delivering something you were praised for.
- Writing really good and consistent release notes
- Keeping documentation up to date
- Being timely with code review so another developer doesn’t have to wait that long to get feedback.
These things are typically hard to measure and are often not visible to the whole team, but they should be commended, encouraged and developed.

The whole team should look for other team members who do these 2 %ers and then do their best to call them out when they see them. Highlighting them and celebrating them will lead to everyone on the team being aware that this type of effort is pivotal to the teams success.

It there a 2 %er that you’ve witnessed a team mate do recently that deserves to be called out? Let them know, let you manager know or mention it in a team call.

It’s all about the 2 %ers!
Consistency: the unsung hero of success

September 3rd, 2021
Consistency is a very undervalued trait. It’s less glorified than taking big risks, or cleaning up some major problem that likely could have been avoided in the first place. It’s a trait that’s not sexy, it’s expected and it’s sometimes invisible.

I really value consistency and aspire to be better at being consistent myself. It doesn’t come naturally to me, I have to work at it and often have to ‘freshen up’ my strategies to keep being consistent.

Some of the reasons I really value consistency are:

1. It takes more time than people appreciate, even if the thing that you do is 5 minutes a day, if you do it every day of the week that adds up to a lot of time.

2. Most people get tired and give up on something, especially when others seem like they aren’t paying attention (just look at all those abandoned podcasts and blogs!)

3. Consistency rarely gets attention, it’s not flashy, it’s often invisible. You’re rarely saving the day with your consistency. Typically you’re preventing drama or problems by being consistency

4. It shows grit and mental strength. There are days where you don’t want to persist because you don’t feel like doing something and it’s easy to not do it because others won’t notice.

5. Consistency is not low hanging fruit.

6. Consistency shows that you value and are willing to work on the thing you want to be consistent about.

With my engineering teams my goal is to make sure that all of their consistent efforts are not invisible. I do my do my best to let the team know that what they’re doing is impressive and it matters.

Unsung hero’s are often consistently working away in the background. We all have these people in our lives:
1. Someone who has dedicated time to coach a junior sports team year after year.
2. Someone who always has a smile on their face when you see them
3. Someone who always volunteers
4. Somebody who sends a report every day
5. A friend who is always makes time to talk to you when you need it
6. Someone who’s always on time
7. Someone who remembers to update training material or documentation when it gets stale
8. Someone who always remembers your birthday
9. Someone who remembers what you order every time you come in
10. Someone who is consistently good at their job and doesn’t mind not being employee of the month or being the best at one thing.
11. Someone who is always good on the sporting field.
We should all make a bigger deal of consistency. Who in your network can you thank for something that they are doing because it’s become invisible to everyone else? How can you reward someone else’s consistency and encourage it? How can you help make consistency valued and visible?

Success doesn’t come from what you do occasionally, it comes from what you do consistently. — Marie Forleo

I’m a work in progress with consistency. But I’m going to keep trying at it 🙂