Solve the right problem

07 May 2015 - sjl

I’ve worked at a few different companies over the years, and been involved in early design work for some large and challenging software projects (aren’t they all?).

Each project invariability throws up it’s unique technical problems and roadblocks along the way. It seems to me that one of the biggest risks, and yet still common occurrences, is not knowing what and where those roadblocks might be until you get there.

That is to say… you don’t know in the early days of a project, which problems are going to be the most important ones to solve. Or how the decisions you make early on are going to help or exacerbate the issues you face later on.

Worse, an inordinate amount of effort is often spent attacking technical problems that turn out to be not the problem that needed solving. Now sometimes this is the nature of the beast. Sometimes you don’t know up front exactly what you’re building, and requirements can change etc. But other times, I think it’s due to a type of tunnel vision on the part of software engineers.

“Our software needs to do X which means we need to do Y. And Y means we need to solve WZQ.”

“And WZQ is really interesting and challenging – so lets dive right into that.”

The really great software teams I’ve worked with are a little bit more careful in the early days of a new project. There are copious whiteboards filled with diagrams. The big picture, and the interacting components become clear to all. The team re-iteratate over the design decisions as it becomes more detailed so as to not go down the wrong path. They try hard to foresee the objective pros and cons of each alternative approach.

The less great teams don’t do that. They skim over details and alternatives. They settle on a “solution” too soon,which can have serious repercussions later on. When they eventually do realise that they’ve taken a wrong turn, they are reluctant to adjust. They are too invested in a particular approach.

Sometimes the tech that seemed like it would be so critical early on is just put aside, it’s use minimsed or even eliminated. But it’s continued existence can serve as a continual reminder of poor foresight and decision making, and a lack of design rigor up front.

How do you avoid this?

Firstly slow down, it you treat software design like a race, you may just finish last. You need to continually test your assumptions as you go. Keep backtracking to check that you haven’t jumped to conclusions about what you actually have to solve to deliver the product required.

Secondly, don’t choose a design that allows you to solve problems you want to solve. Choose the design that entails solving the fewest problems and/or is mostly problems that you know how to solve. That is, fight complexity at every turn.