Archive for April, 2011

Problem Solving, SOA, Agile, Legacy Replacement and Watermelons

Monday, April 18th, 2011

There are no big problems, there are just a lot of little problems. – Henry Ford

Most reasonable people would agree that the smartest way to solve a problem is to break it into smaller pieces.  Sometimes, though, when we’re close to the situation we need to find a way to take a step back and look at the problem differently.

As this baby found out, taking on the whole watermelon was never going to work, so (with a little help) he took a step back (figuratively, because he seems like a pre-walker) and approached it differently:

Recently, one of my teams was facing a challenge.  They were making frequent changes to some complex code and each change would be very time consuming.  .There were many different places where this challenge was presenting itself.  Pretty quickly into the brainstorming session, someone came up with a solution that would eliminate about 60% of the places where this problem was happening – in other words, 60% of the problem would be eliminated resulting in a big productivity gain.  Awesome, right?

I then watched something that struck me….a room full of smart people spent almost an hour shooting holes in this solution because of “the other 40%”.  The group went back and forth and concluded that they couldn’t solve the problem and that everyone would go back and think about it – then get back together in a week.

I jumped in with the idea that they invest the small effort to implement the solution that would fix 60% of their problems and then look at the other 40% as a second problem to solve.  While this was pretty obvious, this group was pretty reluctant until I explained what I thought was the path they were on:

  • Another week was going to pass with them running into this efficiency problem (and someone quickly calculated that the effort for the quick fix was going be less time than they were going to save within a week or two)
  • They probably weren’t going to find a solution during that week and when they got back together, they’d just re-hash what they already talked about
  • If they think they came up with a solution that covers everything, they’d probably realize while  implementing the solution that it really didn’t cover everything and as they “peeled the onion”, the work would grow and take longer and cost more than they expected
  • In the rare event they came up with an all encompassing solution, it would probably be too big to justify doing anytime soon and they’d be living with the pain for a long time
  • Then, as time goes on, the problem will grow and the solution will become that much more difficult

I also explained that after we implemented the solution that knocked out the 60%, the remaining problem would become clearer and could probably be broken down even further.

  • Why do so many people on software projects forget to break their problems down into smaller pieces? First, they “know too much”.   I once had a CFO tell me that he could solve bigger software development problems than the average programmer because he didn’t know as much as they did.  When I heard this, I thought it was ridiculous, but he insisted that they would allow all of the things they know get in the way of solving the root problem.  He said that he could assume away a lot of the variables and make them constants, while the programmer would try to solve the problem with too many variables.
  • Sometimes people are afraid that there is a solution to the whole problem and that they’ll look bad when someone else comes along with that solution and plays Monday morning quarterback on your work.
  • Sometimes solving the smaller problem results in having to go back and do some rework when you get to one of the subsequent problems.
  • There’s always the “hero complex” –people want to solve “hard problems”, not the “simple problems”
  • Let’s face it, most people on development teams grew up hearing that you want to think everything through, get it right the first time and eliminate all that wasted rework.  It’s part of our DNA.

Now, most companies are moving to iterative or agile methodologies and have realized that it’s OK to make quick decisions without all of the information.  It’s OK to have to go back and rework some stuff.   Implementing something is better than coming up with the most elegant solution that never gets implemented.  Predictability is important to companies and it’s a lot easier to predict smaller pieces of work.

I’d much rather solve simple problems than not solve the real complex ones.   This is the same approach I try to take with everything (SOA, Agile development, incremental legacy system replacement, or eating watermelon – to name a few).

Tom Famularo

FAST