Principles and Practices: Solving the Right Problem

This is a further post in the series I started about the Principles and Practices of Software Craftsmen.

In this post I’d like to explore a specific principle that flows pretty readily into a practice that I think is very common among software craftsmen:

Solving the Right Problem
Craftsmen often have a somewhat different perspective on what they do as developers. They understand enough of how IT fits into the business picture to be aware of what is really needed when given a project or even a single story.

Part of the value of an experienced professional in software development is their ability to not only perform the exact task they’re set, but also to help determine if the problem is being solved in the right way. Feature definition is not just a business analyst or customer proxy rattling off a list of acceptance criteria, it’s a give-and-take negotiation. Part of that negotiation is cost-based – the developer can give detailed estimates on specific parts of a story, and the customer proxy can decide to change parts of the story to maximize the value they get for the effort expended.

In addition, however, the experienced craftsman has to have a context of the overall project, and the business advantage that is expected from the development effort. He can then blend this with the technical understanding of *how* it’s going to be done to help figure out if there is a better (e.g. faster, easier, higher quality, more maintainable) way to do accomplish the same thing.

Even beyond finding a better way, the true craftsman can determine if the problem being addressed is even the right problem.

Generally, the user has a good idea as to what they want to accomplish, but not necessarily how they want to accomplish it, or how the features for accomplishing it might be turned into actual working software. This is where your craft comes into play, helping to “translate” the users desires into actual requirements that make the best sense given the context of the existing system of what’s possible.

Sufficient experience often allows a craftsman to look at the requirements user is putting forward and to understand the underlying need for functionality. This may be very different than what you’re actually being told, and to gain experience is the guide for the craftsman to be able to steer the user from what they think they want to what they actually want. This is not at all the same as telling the user that he’s “wrong”, It’s more a matter of being technique being able to communicate with the user at their own level, and to help them explore the problem at hand more thoroughly in the context of what’s possible with software and automation, to arrive at a superior definition of the problem to be solved.

This is what I like to call “solving the right problems”, and it is generally a core principle of software press craftsmanship.

Don’t Grab the Wheel

One way to block this process, and one which I have seen happen frequently in actual practice, is for the customer, customer proxy, or other management, to oversteer technical choices that are not entirely within their domain.

Sometimes this is a trust issue, in the sense that management may not trust the developers, in this case the craftsman, to make the correct choices. Sometimes it is out of a misguided sense of fear, which manifests itself in a desire to have influence over choices that management feel would be “safer”. Frequently, this means selecting and “standardizing” on obsolete, unsuitable, and unproductive technologies and techniques.

The irony, of course, is that in the process of specifying these unsuitable technologies and techniques, the overall risk in the project goes up dramatically.

Software is unique and a bit strange in the fact that it’s the one industry where the customer generally tells the vendor not only what problem they want solved, but how to solve it, and frequently even with what tools to solve it with.

It is somewhat like going to your doctor with a tummyache and telling him “I want my arm amputated, and I want you to use this spoon to do it with”. Oh, and I want it immediately and I want to pay 4c for the service, and it better not hurt. Or going to a master carpenter and telling him “here’s a chunk of pine, make me a mahogany bannister for my staircase, and here’s a blunt butterknife to do the carving with”. While both of these sound absurd, they are no less absurd than hiring a software craftsman and telling him he must develop on a laptop using PHP and MS-Access and deploy on a five-year-old Windows 95 box with insufficient memory. (Not knocking any specific technology here, just pointing out that it’s bad to not make use of your developers expertise).

To get the best out of your craftsman, let him (or her, as I keep pointing out) do the driving. There may be necessary constraints of course, so explain them – but don’t grab the wheel out of his hands.

Principles and Practices

Tired of the Software Development Grind? Know it can be done better? Check out my book: Principles and Practices of Software Craftsmanship or sign up for my Craftsmanship Dispatches newsletter.

Published: July 01 2011

  • tags: