Solve The Real Problem
On November 27, 2000, I walked into a new job that would eventually save my career in software development. I was 18 months out of university and had been through several horrible projects. I had been stuck in consulting land, flying to the nether regions of the Maritimes and participating in back-breaking requirements gathering death marches and silly little one-off projects. I had told my wife that if InfoInterActive (IIA) didn’t work out I was going to find another industry to work in. I was serious.
So I walk into IIA and one of the first things I notice is a banner on the wall of the engineering department that reads “Solve The Real Problem”. I thought to myself “Hmmm, that sounds logical. I wonder why I’ve never heard that phrase before?” For the next two and half years I learned exactly how to apply “Solve The Real Problem” and it is because I learned how to “Solve The Real Problem” and how to develop software successfully that I am still a software developer today. Despite the fact that I have since moved to Calgary and gone through more distinctly non-”Solve The Real Problem” type projects, I still know that it can be done and that giant robust software systems can be built with an extremely high degree of quality and velocity. Two of the leaders of “Solve The Real Problem” at IIA are Brad Spencer and David Benoit. I consider them co-founders of pliantalliance.org since they really are the ones who came up with it. (Despite having posting privileges here, they have yet to post anything … nudge, nudge.)
Solve The Real Problem. Period.
on June 29th, 2006 at 7:29 am
“Solve The Real Problem” has been my motto for many years. It applies to so many things other than software engineering! However, in software, unlike with concrete real-world objects, it is sometimes harder to trace the symptoms that get reported back to their root problem. I have seen how some other companies attempt to patch software at the symptom level and it usually ends up in a legacy of code that becomes unmaintainable.
Solve The Real Problem. If you don’t, you will have to live with the consequences. The longer you wait, the harder it will be to un-fix all patches.
on June 29th, 2006 at 7:32 am
Solve The Real Problem. If you don’t, you will have to live with the consequences. The longer you wait, the harder it will be to un-fix all patches.
This of course applies to both the software itself and the process used to build the software.
on June 29th, 2006 at 7:32 am
Nudge felt. I offer to you my musings from July 2003 on some related principles.
Solve the whole problem.
This is the corollary to solve the real problem. If you are building a function, a class, a library, an application, or a system, by solving the real problem, you make sure you clearly delineate the areas of responsibility of yourself and others using a well-defined interfaces. By solving the whole problem, you ensure that the well-defined interface best represents the most appropriate division of responsibility. This idea can be represented by the notion that a system component should make the work it does significantly easier for clients if they use the component versus doing it themselves.
The implementation is more flexible than the interface.
If you have well-defined interfaces dividing areas of responsibility, then you “write to the interface”. Doing this properly and taking advantage of the abstraction requires designing the interface to match the division of responsibility (i.e. solving the whole problem) and then writing the code to implement as much of that interface as is necessary (maybe all of it). The wrong thing to do is to write an interface that matches (read “exposes”) your current implementation out of convenience and then be jailed to that implementation forever.
Never let perfect stand in the way of very good.
It may be tempting to wait until you have the time, the knowledge, or the inclination to design the “perfect” solution, especially if you aim to solve the real problem. However, you must temper this instinct with practicality. While it may look like you are holding out for “the perfect solution” (that solves the whole, real problem), what you are really doing is preventing “the very good solution” that can be applied in the interim. We must recognize that perfection can only be approached asymptotically through evolution of design and implementation: in essence by refining our deployed very good solutions to make them more perfect. Solving the real problem should be applied where scope allows and it should guide our path to tell us where perfect is, but we are allowed to get there in more than one step. Very good solutions have value, and value delayed is value lost.
This last principle developed out of seed ideas from David Trueman here at IIA and serves as an important balance to the other three. It represents the “real world pressures” and reminds us that the real goal is to produce something, after all.
on June 29th, 2006 at 7:35 am
We must recognize that perfection can only be approached asymptotically through evolution of design and implementation.
Again, this can also be applied to how the software is developed. :)
on June 29th, 2006 at 11:33 am
While it may look like you are holding out for “the perfect solution” (that solves the whole, real problem), what you are really doing is preventing “the very good solution” that can be applied in the interim.
We must also admit that there is no silver bullet. As much as people write about processes that will “solve all problems” there is no way to do that, just as there is no one pair of pants that will fit every human on the planet. What we have instead is the ability to recognize when what we are doing, and what we have done in attempting to solve the real problem has failed. Regroup. Rethink. Rewrite.
on June 30th, 2006 at 10:44 am
This content would make a great article. :)
-Jonathan