On the Danger of Software Magicians
Software can seem like magic. Programmers wave a magic wand and recite an incantation and work happens and things get done. We can fix problems by changing a few inscrutable characters.
More than that, it feels good to be hailed as a magician. Sweeping in to save the day at the 11th hour, pulling success from the jaws of some approaching calamitous end.
But we shouldn’t encourage this notion. Software isn’t magic, and we shouldn’t allow it to be thought of that way.
The dangers of software magic
I had a coworker at a previous job who would often hack through the weekend in order to make a working proof of concept to show off to bosses. I had to break him of that notion. Management would see something working and expect that we were done. They would think he was a magician.
What they didn't know was that code was terrible. It had no tests, documentation, comments. It wasn't legible, extensible, sensical. It eschewed best practices, or even normal practices, in order to get things done.
It copied and pasted.
A lot.
Try to convince management that you need 3 weeks to complete a piece of software that was written in 12 hours and appears to be working. Its a tough sell. They can't see how badly built that software is. They don't know what horrors to expect down the road when that code reaches production.
What stage magicians do
You go to Las Vegas, buy your ticket, and sit in the theater. The lights go down and your evening's host comes out on stage. “For my first trick, I'm going to create a house, here on stage in front of your very eyes.” The magician waves a wand, music is played, some curtains flutter, and decorative panels spin on caster wheels.
A flash!
Suddenly a very life-like house is on the stage. The walls look rigid, the shingles fresh, the paint perfect. A good-looking assistant waves from a window; they baked a pie in the kitchen, they show you.
But you know its a trick. You know that if you could walk into that house, you'd see quick-release clamps holding it together. There are no stairs to that second floor; there is no kitchen to bake that pie. There is no plumbing, electrical, air ducts, joists.
What software magicians do
Software magic is no different. Software that shows up as if by magic has all the same flaws as a house that shows up by those same means. The problem is that since software isn't tangible the untrained eye can't see it.
They see a functioning widget. The data ends up in the database. The email gets sent. So it works right?! You are a magician.
Sure it works, but for how long? Will you be able to improve it when needed? Will a new developer understand it when they join the team? Will it fail catastrophically when presented with data that doesn't conform to assumptions?
You know that magic act was a sham, why do you expect software magic to be anything else?
What software developers (should) do
We try to build software that is analogous to a craftsmanlike house. We build software that predicts points of extensibility and mitigates future problems. It should have tests to be sure we don't break it later and documentation to describe how it works to the next developer.
We want to be craftsman that build a strong structure. We aren't magicians, nor should we appear to be. Management needs to know this, respect it, and even want us to do the job well.
It can feel good to be called a magician, but please, don't take it as a compliment. For me, the best compliment is “you've done a good job” not “that was magic”. No, the best compliment is when my software works and continues to work.