Too Busy For Words - the PaulWay Blog

Mon 13th Aug, 2007

The "solution giver" problem

Andrew Bennetts recently linked to Nicholas describing the kinds of a problems that programmers can cause by not thinking things through. I went to add a comment to this, but since LiveJournal decided that that was too difficult I put it here instead. It also references something I was talking about with the people at PSIG last Thursday night, for a bit of extra relevance.

To me, programming today is like being an engineer in the early days of the industrial revolution, where new devices were created for new tasks seemingly every day - exciting and filled with endless possibilities. The problem Nicholas describes is that we usually don't have much practice, and a lot of programmers have never done any formal training, in order to execute our plans well. There's one other big problem that I see in the industry, as well.

Most of us enjoy solving problems. If someone asks us for a new shower, we do it ourselves for the challenge rather than refer them to an actual builder. But, especially in employment, this has a downside. If a manager goes to his programming team and says "We'd like to call up dread Cthulhu and all his ghastly horrors from the nether pit of hell", the programming team will say "well, I suppose we could try randomly reading pages from the Necronomicon." No-one will say, "no, calling up dread Cthulhu and all his ghastly horrors from the nether pit of hell is a bad idea and you should not do it," nor will they say, "how about you go to Arkham Asylum and ask them to do it, because we aren't touching this one with a mystic pentacle." In our eagerness to solve problems, we not only implement stupid things that should not be, but we make our own lives a living hell. Sometimes, we have to resist the temptation to solve the problem as presented and instead answer the questions, "should we be doing this?" and "is there a better way to achieve the end result?"

This also manifests itself in choosing how we solve the problem. Usually there are a variety of ways to implement a new feature, or fix a bug; in our haste to explore all these options we often point out that there's a quick and dirty kludge that will probably fail but might just work. Management (at least, the traditional management that most techies face) will always choose that option - partly because they don't actually have to live with the consequences, and partly because they often don't realise that support time is always orders of magnitude larger than development time. They see it as simply playing the odds: if we luck in, the business gets the problem solved cheaply. We need to be strong when presenting solutions and do things the right way, rather than making rods for our own backs.

There's heaps of other problems: the missing example problem, the testing problem, cargo cult programming, the 'learned blindness' problem, the "yak shaving" problem (with a tip of the hat to Mikal Still) and more. But I've nattered on enough already. :-) Maybe I should put this into a "Programming 201 - The Things Your Professors or Hacker Buddies Know But Never Told You About How To Program Right" talk for a future LCA. It needs a catchy title, though. How about "Argh, The Giant Clams, Get Them Off Me!" or "Press The Button And Watch Paul's Brain Really Explode!"

Last updated: | path: tech | permanent link to this entry


All posts licensed under the CC-BY-NC license. Author Paul Wayper.


Main index / tbfw/ - © 2004-2016 Paul Wayper
Valid HTML5 Valid CSS!