When trying to come up with a solution to a problem, the technique I’ve been taught most of the time, but not necessarily the one I see employed most of the time, is to brainstorm first. Perhaps using mind-mapping to capture the thoughts and suggest new ones. Then, once the ideas have been captured, prioritize them and come up with a plan.

That’s not a bad way to start, but doesn’t really solve the more intractable problem. What if the problem being solved isn’t the right problem?

Consider our two earlier people container developers. I think both of them came up with what would ordinarily be regarded as reasonably smart, clever, and cost-effective solutions for the problems they were trying to solve—protecting a man and woman from predators with a budget of about $10,000 and a schedule of three months. The traditional developer came up with a metal cage, and the agile developer came up with a large upside-down bowl woven from saplings surrounded by bells on wires. The agile developer would have criticized the metal cage as having been over-engineered. The traditional developer would have criticized the wood-and-leaf bowl as being substantially less appropriate for the customer’s long-term needs, or for larger projects.

However, both projects were, in my opinion, over budget and over schedule. In neither case did the customer have the basic need truly met by his deadline and without asking for more money. The traditional developer simply underestimated his job; that happens very frequently with software development. The agile developer technically met his deadline, if we use an extremely generous perspective, but exceeded his budget. (I believe agile developers would generally try to avoid being stuck with a long-term deadline.)

Is there a way to get the customer to express his needs to either developer, or both, in such a way that invented solutions could be quickly estimated fairly accurately? I’m not sure there is. How can anyone know what it will cost to solve a problem which hasn’t really been asked clearly yet?

I should point out about now that I will have to totally abandon the metaphor linking software development with building construction. Software is a continually evolving mechanism, having to deal with extraordinary changes to its environment as well as dramatic changes (or clarification) of the customer’s needs, whereas buildings tend to need much less evolution over time.

What could we compare it to, then, in order to learn from previous experience?

Art? No. While its true that the production of an idea generally ranges from moments to days, and, more rarely weeks, the gestation of that idea has no direct correlation. It could come in a flash, it may never come at all.

Medicine? No. Medicine is chiefly concerned with diagnosing, treating, and researching problems. The treatments would be most closely associated with creating software, but rarely are treatments an enterprise in constructing something completely new from imagination.

Producing movies? No. While the creative elements of making a movie are difficult to predict—getting the script right, finding or making the music, set design, etc.—the structural process of creating a movie remains generally the same from one movie to another, large or small, long or short.

It’s a little like all fields of work, and yet not quite like any of them. There are creative aspects, even when we assemble enterprise information systems. There are basic constructive aspects, even when we’re experimenting with prototypes. There are diagnostic aspects, even when we’re creating greenfield software.

I suspect that the eventual change that will have to happen is that we begin systematically, professionally, and uniformly presenting the creation of software as a completely different endeavor than is traditionally used to solve problems like constructing a bridge, publishing a book, fixing a watch, whatever.

We really are tasked with reading the dreams of our customers, understanding where the opportunity is present, suggesting ways to solve it while having a very good ability to say what the costs of solving it should be.

Makes me wonder if I should have been a professional bowler, instead.