Don’t Be a Problem Solver

?

Don’t Be a Problem Solver

Eben Hewitt

WiTH SoME ExCEpTionS, ARCHiTECTS uSEd To BE dEvElopERS. Devel- opers get rewarded for solving programming problems, which are more local in scope than architectural problems. Many programming problems are small, tricky, algorithmic problems. Such problems are frequently presented in pro- gramming interviews, books, and university courses as if the problems exist in a vacuum. The trickiness is alluring and seductive. Over time, we begin to accept such problems out of hand. We do not ask if this problem is meaning- ful, or interesting, or useful, or ethical. We are not rewarded for considering the relation of this problem to a larger landscape. We are trained to focus only on our solution, which is aggravated by the fact that solving hard problems is hard. We leap into action in programming interviews, which often begin by presenting us with some number of jelly beans we are meant to sort accord- ing to an arbitrary set of constraints. We learn not to question the constraints; they are a pedagogical tool, intended to lead us to discover what the teacher or interviewer or mentor already knows.
Architects and developers learn to enter problem-solving mode immediately. But sometimes the best solution is no solution. Many software problems need not be solved at all. They only appear as problems because we look only at the symptoms.
Consider managed memory. Developers on managed platforms have not solved memory problems, nor could many of them do so if required; part of their solution means that they mostly just don’t have that problem.
Consider complex builds that demand lots of interconnected scripts requir- ing the enforcement of many standards and conventions. You could solve that
?
??problem, and it would feel great to get it all to work, putting your best scripting skills and best practices to work. Our colleagues will be impressed. No one is impressed by us not solving a problem. But if we can step back and figure out that we aren’t solving a build problem but rather an automation and portability problem, this might lead you to a tool that abstracts it away.
Because architects tend to immediately enter problem-solving mode, we for- get, or rather have never learned how, to interrogate the problem itself. We must learn, like a telephoto lens, to zoom in and zoom out, in order to ensure that the question is really framed properly, and that we’re not merely accepting what we’re given. We must not be passive receptacles for requirements, cheer- fully ready at our posts, handing out our smartest solutions in the manner of a Pez dispenser.
Instead of immediately working to solve the problem as presented, see if you can change the problem. Ask yourself, what would the architecture look like if I just didn’t have this problem? This can lead ultimately to more elegant and sustainable solutions. The business problem still does need to be solved, but not, perhaps, as immediately suggested.
We have to break our addiction to “problems.” We love to get them, seeing our- selves on a European bridge, as if we are secret agents who’ve just been handed a self-destructing brown envelope containing our mission. Before considering your answer to a problem, think what the world would look like if you just didn’t have this problem.