Don’t Rely on “Magic Happens Here”

Don’t Rely on “Magic Happens Here”

Alan Griffiths

iF YOU LOOK AT ANY ACTiViTY, process, or discipline from far enough away, it looks simple. Managers with no experience of development think what pro- grammers do is simple, and programmers with no experience of management think the same of what managers do.
Programming is something some people do—some of the time. And the hard part—the thinking—is the least visible and least appreciated by the uninitiated. There have been many attempts to remove the need for this skilled think- ing over the decades. One of the earliest and most memorable is the effort by Grace Hopper to make programming languages less cryptic—which some accounts predicted would remove the need for specialist programmers. The result (COBOL) has contributed to the income of many specialist programmers over subsequent decades.
The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obvi- ously naïve. But the mental process that leads to this mistake is part of human nature, and programmers are just as prone to making it as everyone else.
On any project, there are likely many things that an individual programmer doesn’t get actively involved in: eliciting requirements from users, getting bud- gets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old processes or programs, etc.
58 97 Things Every Programmer Should Know

When you aren’t actively involved in things, there is an unconscious tendency to assume that they are simple and happen “by magic.” While the magic con- tinues to happen, all is well. But when—it is usually “when” and not “if ”—the magic stops, the project is in trouble.
I’ve seen projects lose weeks of developer time because no one understood how they relied on “the right” version of a DLL being loaded. When things started failing intermittently, team members looked everywhere else before someone noticed that “a wrong” version of the DLL was being loaded.
Another department was running smoothly—projects delivered on time, no late-night debugging sessions, no emergency fixes. So smoothly, in fact, that senior management decided that things “ran themselves,” and it could do without the project manager. Within six months, the projects in the depart- ment looked just like the rest of the organization—late, buggy, and continually being patched.
You don’t have to understand all the magic that makes your project work, but it doesn’t hurt to understand some of it—or to appreciate someone who understands the bits you don’t.
Most importantly, make sure that when the magic stops, it can be started again.