On Solving Problems That Matter
Engineers are usually pretty good problem solvers and so are software developers (which I also consider to be part of the engineering guild). But if that is the case, why is there so much crappy mediocre software around where people have apparently failed miserably at solving a certain problem?
Over the last few years I have come up with a theory for this, which I would like to elaborate on during the rest of this article.
There are probably a dozen of factors that have an influence on whether the result of a project will fall into this category or whether it will be fun to use. In the end, however, I think there are only two major aspects that significantly influence the result of a development project: Motivation and a sound understanding of the problem domain.
Motivation is a little hard to grasp. One can’t force people to be motivated and attempts to motivate them through financial incentives (think “bonus”) actually do not work that well. Actually, they seem to be counterproductive. So let me postpone this factor until later as there seems to be a solution for the second important aspect, which magically also solves the motivational issue.
Second issue: A good understanding of the problem domain. Shouldn’t be too difficult, right? We build product a / feature B, because… ehm… because… Actually, it turns out that this one is not as easy as it sounds. For large commercial software engineering projects it is often pretty difficult to retrospectively find out why a certain feature was chosen for implementation over another. Yes, there are decision making tools, such as planning poker or buy-a-feature that are supposed to help, but still the decisions are usually taken by people based on budget or resource constraints and in no way reflect what an actual user may expect or need.
So, everything is lost? People building software are building features they can not relate to on the basis of questionable motivational incentives? I don’t think so…
There is plenty of great software out there and I think the big difference between this great software and software that you don’t even want to use if you are paid for it is that the former is built by people to solve their own problems, problem that matter for them. Because if they finish the project that means that they will afterwards have at least one happy user (the developer himself) - a property, which does not apply to all projects. And what, if not solving a problem of my own, provides a strong intrinsic motivation to work on a solution?
Don’t get me wrong: I am not saying that all software that is built by people just because they are paid for it is inevitably bad. I am just saying that chances of building something that really stands out (in a positive way ;-)) are much higher if people are building it for themselves because they build it with an intrinsic motivation.
[Update:] I Think many of Google’s projects that emerged out of a 20% project are a good example of such great software in a commercial software universe. People started building them because it was fun and they were maybe looking for a great web-mail client. The result was GMail/Google Mail. Google TV, on the other side, does not seem to hold up to the promise of getting things right, but I doubt that this has started as a 20% project…