Solving the Right Problems

Why do we try to solve the wrong problems?

The majority of software development is some form of maintenance of older applications written by developers long gone from the organization. While we do get an opportunity for a green field project once in a while often times we are called in to augment a system that either needs to be retired or scaled to meet the current needs of the business. Oftentimes a junior developer will curse the previous engineers for not building the application to modern standards and the current business needs. With experience it is easy to see that deadlines, limitations, market fit and the needs of the business often trump any grand architectural designs. A business can only afford as much application as solves the immediate challenge in the marketplace and no more.

As we dig through the remnants of creaky yet functioning code bases many quizzical designs appear. Many times I have asked many questions and made many statements while digging through legacy code. Ah! Look at this fine gem this is when the developer learned about Ruby on Rails mvc style development. Oh nice some functional style methods. Interesting early initiatives into reactive programming what a gem. Those are the more enjoyable ventures of seeing when certain programming fads came into style in a code base. Most of the time the frustration is more often when the developer or the business did not communicate the right problem being solved by the software. Ultimately assigning blame is a total waste of time and whether the business problem is solved poorly or well. Solved is solved for the business. While for the developers diving into a legacy codebase, a succinctly solved problem is much more preferable. Less preferable is the problem solved with every possible feature of object orientation, inheritance and interfaces.

Why is the business giving me the wrong solutions?

A common occurrence of solving the wrong problem is taking the business literally when it describes its problem and possible solution. An example I give is someone that is new to bicycling goes to the bike shop for bike maintenance. This person walks their bike in and starts talking with the staff. “I want this bicycle to have car turn signals on it, how much would that cost?” The staff member is experienced and knows how this bicycle rodeo goes. “So, you would like to be more visible when you are riding your bicycle? I can help you find materials to help with that and it would be cheaper than a car’s turn signals”. The pateron responds, “Oh sure, that would be great”.

As professional crafts people we have to be aware that our clients often do not know the best solution to their problem but do want to offer up a possible solution.

How can we solve the right problems?

Slow down and listen. Talk with the business and ask what would expected best outcomes look like? Fight any feeling to provide or discuss a solution until the exact problem is well defined.