This entry comes from a guest blogger who wishes to remain anonymous for now. As he wrote to me

I’d blog about this but some parties to whom this is directed might end up reading it and get offended. So prepare for a rant. :-)

The image is so vivid that I had to post this on his behalf. Enjoy.

The most dreadful style of programming is shotgun programming. Perhaps you’ve heard of cowboy coding. This is its ugliest, rudest form. A cowboy at least uses a pistol, a weapon which in the right hands can be wickedly accurate and effective. But the shotgun-totin’ programmer makes for a completely different game. It’s a wild, drunken attack at the keyboard, launching random code at the compiler and seeing what sticks. It ignores all logged messages and compiler warnings. Documentation is never consulted. Who actually reads that stuff anyway? Thinking before shooting is not just discouraged, it’s never considered. Who needs to think when you’ve got a bloody shotgun!

The way a shotgunner approaches programming is to blindly start shooting first and then ask questions later. And when something does work, well, don’t sit around worryin’ about why, just start doin’ it again! Do it again and again and again. It worked once (somehow) so it must work again, right? To take the time to understand why or how something works is a waste of time. I suppose it’s a sort of evolutionary approach to programming, where intelligence and design have no place.

And when I say blindly, I mean the “blind-folded swinging at the pinata” style. It starts with wild swings in any direction. Who knows what the right direction might be? That’s impossible! Computers are magic black boxes (of the devil, I might add). As soon as something connects, whether or not it happens to actually be the piñata, you beat the hell out of it. Of course, you never take the blindfold off to see what you’re doing, so you end up with a bloody pulp of code.

What am I talking about specifically? I’m talking about spending hours randomly debugging a problem when looking at the actual runtime error message would lead you directly to the bug within minutes. I’m talking about never, ever, looking at the documentation. I’m talking about cut and paste-ing the wrong code, sometimes entirely different applications, that’s right, cut and paste as a whole, and then strangling it into submission. I’m talking about learning one compilable trick and then using it for every solution. Or it’s the other extreme of the engineer who thinks good code is measured by the absolute number of design patterns and acronyms one can cram into an executable. It’s randomly adding methods to whatever class happens to be within reach at the moment with no thought of encapsulation or separation of concerns. I’m talking about fundamentally not caring about what it is you end up with and what depths you sink to along the way.

Of course, shotguns are so 1999. With today’s modern code generating IDE’s we allow former shotgunners to lay down their punitive arms and take up carpet bombing their code instead. And that tragedy is another rant all to itself.

Epilogue

Now it’s almost the end of 2015, and what this guest blogger wrote nine years ago sounds a lot like a human running a genetic algorithm for writing code. This seems risky and invites failure. Even if it gave birth to code that worked, it would almost never give birth to a sustainable design, for even a small problem. Given enough cowboys and enough keyboards, perhaps…. It seems like a bad investment to me.