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 is more local on scope than architectural problems. Many programming problems is small, tricky, algorithmic problems. Such problems is 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 don't ask if this problem is meaning-ful, or interesting, or useful, or ethical. We is not rewarded for considering the relation of this problem to a larger landscape. We are trained to focus for our solution, which was aggravated by the fact that solving hard problems was hard. We leap into action in programming interviews, which often begin by presenting us with some number of jelly beans we is M Eant to sort accord-ing to an arbitrary set of constraints. We learn not to question the constraints; They is a Pedagogical tool, intended to leads 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 being solved at all. They only appear as problems because we look only at the symptoms.
Consider managed memory. Developers on managed platforms has not solved memory problems, nor could many of them if required; Part of their solution means that they mostly just don ' t has that problem.
Consider complex builds that demand lots of interconnected scripts requir-ing the enforcement of many standards and Conve Ntions. 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 would be impressed. No One is impressed by us not solving a problem. But if we can step back and figure out the we aren ' t solving a build problem but rather an automation and portability pro Blem, this might leads you to a tool that abstracts it away.
Because architects tend to immediately enter problem-solving mode, we for-get, or rather has never learned how, to Inter Rogate the problem itself. We must learn, like a telephoto-lens, to-zoom in and zoom out, in order-to-ensure, the question is really framed prope Rly, and that we're not merely accepting "what we ' re given. We must not being passive receptacles for requirements, cheer-fully on our posts, handing off our smartest solutions I n 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 has this problem? This can leads ultimately to more elegant and sustainable solutions. The business problem still does need to being solved, but not, perhaps, as immediately suggested.
We have the addiction to "problems." We love to get them, seeing our-selves on a European bridge, as if we were secret agents who ' ve just been handed a self-de Structing Brown envelope containing our mission. Before considering your answer to a problem and think what's the world would look like if you just didn ' t has this problem.

Don ' t be a problem Solver