Code Isn't Magical, It's Just A Series Of Commands
For many people, it seems that working on a piece of software is like stepping into the "fog of war". There's a general sense of bewilderment about how any of it works; and a constant fear that even small changes made anywhere might suddenly cause a collapse of the entire system. But this fear is almost always misplaced. It stems from the notion that code is somehow magical. But code isn't magical, it's just a series of commands.
To overhear conversations between developers, you might come to believe that software suffers from quantum entanglement. That is, changes made in one location of a code-base mysteriously impact the behavior in another part of the code-base.
But, none of it is mysterious—it's all right there on the screen. Even the mostly tightly coupled, garbage code you've ever seen—or ever written—is still just a bunch of object references and method calls.
If you need to change a line of code, simply ask yourself two questions:
- Where did I get the inputs?
- Who relies on the outputs?
Answering these questions might not be simple; but, considering the code in this light removes the air of mystery and reduces the problem down to a set of quantifiable values.
And, more often than not, answering these questions is actually easy. Because, most of the time, a piece of software isn't one giant concept—it's actually a lot of small isolated concepts that sometimes communicate with each other (though object references, methods calls, and queues). And, each one of these concepts can often be considered—and maintained—in relative isolation.
I'm not saying that maintaining software is easy—I'm only saying that it's not nearly as hard as you might believe it is. If you learn to think about request processing as a linear process that's implemented through a series of method calls, the world becomes much smaller and more manageable.
And, if you focus on writing code that's easy to find and easy to delete, your software will become more maintainable over time, not less; even as it grows in size.
Reader Comments
After I wrote this post, it got me thinking about something I've been hearing off-and-on for a while on a variety of podcasts. This notion that the size of a JavaScript application somehow has a direct impact on the runtime performance of said application. I believe this sentiment is allowed to take root in people's mind because they have this magical thinking mindset—that they've lost connection to the actual mechanics of the page request-response life-cycle:
www.bennadel.com/blog/4694-javascript-application-size-shouldnt-affect-performance.htm
Who relies on the outputs?is the key question here. Without that information, thoroughly testing a refactor IS scary. Now, proper test case coverage can drastically reduce that fear, but... who has 100% coverage?As for output reliance, that way our particular code is structured, aside from a few
<cfinvoke>calls (I hate those, but I get it...) we can usually search forservice.function(and find most of the calls. Fortunately, our architect focuses on the ability to maintain the code, then focusing on optimization.@Will,
It's a good point about meta-programming techniques like
CFInvoke()—that's exactly why I try to shy away from anything that builds dynamic invocation: it makes that code harder to find. The more clearly you can names things and the more clearly you can reference them, the easier it becomes to find.There's also a big difference between day-1 work and day-100 work. If you step into a code-base for the first time, you have so little evidence upon which to operate. But, as you work in a project, you get a sense of how things are laid out and the naming conventions and which services are used a lot and which services are used rarely; and, by day-100, it's much easier to just have a "feeling" about what needs to be done; and then to go do it.
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →