While our software industry is trying to grow in multiple aspects, we are still trying to work out why IT projects fail. One of the reasons, and the most severe one in my opinion, is that a lot of us jump to a software solution without trying to identify and understand the problem.
It may be over-confidence because of expertise or eagerness to write code or maybe to just sell something that ignores the problem that the user is facing.
Or it may be that we try to modify the problem to suit our solution, instead of the other way round. As Joel says:
Time and time again, you’ll see programmers redefining problems so that they can be solved algorithmically. By redefining the problem, it often happens that they’re left with something that can be solved, but which is actually a trivial problem. They don’t solve the real problem, because that’s intractable.
I have seen a keen desire among software designers to automate every single thing, without thinking about its cost and implications.
Or it might be the misconception that the real challenge is in building the solution. As Bertrand Russell says:
The greatest challenge to any thinker is stating the problem in a way that will allow a solution.
But this does not mean modifying the problem to make the solution easier. It is about asking the right question, and about stating the problem statement clearly and explicitly. It is a true challenge the identify the implicit and unsaid requirements and constraints, and document the problem. That is the only point where ROI of the software can be realized, if not measured.
Or it just might be that our processes and project management techniques are not mature enough to consider real world issues. It is very tempting to postpone discussing certain issues in favor of what you know and what is visible.
The problem itself can stand for the value of the software, but there is another reason why it is important to understand the problem before you even start with software, only software itself is never the solution. The solution will always involve more than the software, and that can stay hidden if the problem is not identified.


December 6th, 2007 at 6:32 pm
Nice Article. I agree with your point that the over-confidence or the anxiousness to code creates a lot of trouble.
December 7th, 2007 at 8:45 am
Thanks Gauri!