The BOSS Method: Blindingly Obvious Software Solutions

What are the secrets software architects use to create amazing systems? In fact if we ask ourselves the question "how should we build our software?", I bet most of us can come up with a pretty good answer. With Microservices? Probably. Automated Tests? Of course. Some kind of Agile process? Who wouldn't? Much of this is obvious and generally we know a lot of what we need to do; the problems occur in the execution.

With this in mind, lets look at some of the ways doing the obviously correct thing can (and does) fail to happen.

Change is scary

The first thing you might encounter is reluctance to do the right thing. Product might not want to "waste" time writing tests. Engineers might not want to create a ticket to track every quick fix. Management might not wish to invest in a microservice architecture. Generally people are afraid to do things differently from the way they have done in the past. Active change management is necessary to get everyone onboard with the improvements you need to make.

We don't have time

Perhaps the most common hurdle is "we're too busy". This indicates one of two things. Firstly not everyone may have actually bought into the solution. Check if senior management and the product team are aligned with the technical team on what needs to be done - then you can carve out the resources to do it. Secondly, you may have the wrong incentive structure. Are engineers really getting recognition for doing the unglamorous behind-the-scenes stuff which needs to happen? Remember that incentives can be both formal (linked to career progression) or informal, such as the good feeling you get when you help out a coworker with their problem. If the latter dominates you need to find a way to remove distractions and make progressing strategic project goals compete with the instant gratification of closing a minor issue.

Been there, done that

Another objection is "we've tried it before and it didn't work!" This tends to shut down the discussion, but it shouldn't. Toddlers don't give up trying to walk after falling down a few times. Perhaps the team didn't have the necessary experience to pull it off before, or circumstances and assumptions have changed. It's rare that an Architecture Decision Record is available to remind us why a decision was made in the past.

Next there may be lack of clarity over what good looks like. Perhaps you think you're already implementing RESTful APIs perfectly well, but you're not doing it correctly. This is often true of Agile processes - your teams may be following the ceremomies and formulae, but due to a lack of understanding of the "why" you don't see the benefits.

We're working on it

Now suppose everyone is clear on what needs to be improved. The most common issue now is that it's taking a long time to achieve. Why is it taking so long? It's likely you don't have people with the right skills working on it. Consider adding a few highly skilled contractors to help you get there.

Last but not least, you may have difficulties applying the textbook approach to the specific complexities of your codebase. The devil is in the details, indeed. This is certainly true and may require a deeper understanding of "why" good practices are good in order to modify them and apply them to your situation, rather than trying to copy a formula verbatim.

To sum up, many best practices for building software are not secret! Don't hesitate to use the BOSS method and pick the really obvious solution rather than trying to invent something unique. Great execution generally won't be easy though, so focus as much energy as possible on the communications, implementation and rollout process.