Solve the right problem

Over on Ryan Abrahamson’s blog is a post entitled “Problem Solving vs. Solution Finding” that is, at best poorly thought through.

I think that Ryan is trying to point out the importance of keeping the end goal in mind when programming - that writing code isn’t an end in it’s own right, but instead merely a means to an end, and that it’s import to be effective and efficient and to avoid wasting time. With this I have no problem - in fact, as regular readers and those who have heard my presentations will recognize, I’m 100% in agreement with the idea.

However, what Ryan actually says is something different, something dangerous.

The Problem Solver will dig in to see why area A is broken, where the Solution Finder will investigate … and solve the problem by potentially working around it.

I’ve worked many with people who fit this “solution finder” approach, and with many of them, the appearance of getting today’s job done is achieved at the expense of tomorrow.

Here are some real world examples where a solution was found but the underlying problem was not solved.

The Student Records System

A database backed student enrollment system at a tertiary education provide where the information in the database was being slowly corrupted by bugs in the application.

The solution? Manually patch the records for those students where discrepancies had been identified.

There was no cross checking of records against the original physical paperwork, no exploratory queries against the database to detect other issues, and certainly no effort to find the causative bugs and prevent future corruption.

From management’s perspective, the original problem was solved - but the scope of the original problem was hidden while data continued to be corrupted.

Database Access by ORM … or not

A significant multi-tier bespoke software system being developed in-house, using a formal object relational mapper (or ORM) to manage persistence of a rich domain model.

When a complex query wasn’t directly supported by the ORM, a workaround solution was written, one that bypassed all the caching and other features of the ORM in favor of direct database access.

Yes, the direct problem was solved, and the developer got to move onto their next task within the project. But, the query couldn’t be reused in any other context as it was too tightly bound to the original use. Worse, the bypass meant the system performed poorly.

A simple rewrite of the query that reused the SQL generation but relied on the ORM for object hydration improved performance by nearly 15%.

The Overly Dynamic User Interface

When faced by the requirement of allowing for large amounts of user interface customisation to suit different customers, one developer’s solution was to store the entire user interface as data, loading it at application start up.

This certainly achieved the desired end result, and the flexibility was used to good effect, allowing many installations to be customized “just so”. Happy customers are a good thing, right?

However, this approach to the problem occurred at an enormous cost to other developers. Any (every!) user interface change now required a substantial amount of tedious work because regular user interface design tools were incompatible with the approach and therefore unavailable. Some kinds of work were 3x or 4x slower than they might have been.

In Conclusion

It’s vital that developers keep their eye on the ball - the goal of delivering business value is more than just a little important. That said, Ryan’s artificial distinction between Problem Solvers and Solution Finders serves only to encourage exactly the wrong kind of short term thinking.

Ryan writes:

In today’s world of … tight schedules I believe that a work around … that takes 8 hours vs. the more pure solution … that takes 40 hours is a more fruitful approach.

The problem here is with the short term thinking, a focus entirely on the current situation without consideration of what will happen tomorrow, next month or next year.

I’ve worked with plenty of developers who focus entirely on solving today’s problem with zero consideration for tomorrows - and I’ve spent altogether too much time cleaning up their messes.

A good developer - an ethical one - develops for the long term as well as the immediate. Addressing the actual underlying problem often takes a little longer than a simple patch up - but it has the undeniable advantage of not requiring on going remedial work later on.

In reality the workaround doesn’t take just 8 hours this week … it incurs an on going cost because you’ve failed to address the underlying cause. You might save time this week, but long term - over the course of a few months or a year - you end up spending more time on the workaround than on a proper fix.

Workarounds that ignore the underlying problem are like taking aspirin to treat a headache caused by a brain tumour. You might feel better today, but the problem hasn’t gone away and one day, well, one day everything suddenly gets very messy.

Why post this here, instead of as a comment over on Ryan’s blog? Short version of a long story, I posted a small comment, but Ryan has refused to publish it.