Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site.
The term “technical debt” has become ubiquitous in the programming world. In the most general sense, it reflects the idea that you’re doing something easy in the moment, but that you’re going to pay for, with interest, in the long run. Conceived this way, to avoid technical debt would mean to avoid taking out these “time loans” in general.
There’s a subtle bit of friction, however, when using the (admittedly very helpful) concept of technical debt to communicate with business stakeholders. For them, carrying debt is generally a standard operating procedure and often a tool, and it doesn’t have quite the same connotation. When developers talk about incurring technical debt, it’s overwhelmingly in the context of “we’re doing something ugly and dirty to get this thing shipped, and man are we going to pay for it later.” That’s a far cry from, “I’m going to finance a fleet of trucks so that we can expand our delivery operation regionally,” that an accountant or executive might understand. Taking on technical debt is colloquially more akin to borrowing money from a guy that breaks thumbs.
The reason there’s this slight dissonance between the usages is that technical debt in codebases is a lot more likely to be incurred unwittingly (or improvidently). The reason, in turn, for this could make up the subject of an entire post, but suffice it to say that the developers are often shielded from business decisions and consequences. It is thus harder for them to be party to all factors of such a tradeoff — a role often played by people with titles like “business analyst” or “project manager.”
In light of this, let’s talk about avoiding the “we break thumbs” variety of tech debt, and how NDepend can help. This sort of tech debt takes the form of “things you realize probably aren’t great, but you might not realize how long-term damaging they are.”
Editorial Note: I originally wrote this post for the SmartBear blog. You can check out the original here, at their site.
If you’re a software developer, there’s a decent chance you’ve been embroiled in the debate over integrated development environments (IDEs) versus text editors. Users of IDEs will tell you that they facilitate productivity to a degree that makes them indispensable, whereas users of text editors will tell you that the IDEs are too big and bloated, and hide too much of the truth of what’s happening from you. In some cases, depending on the tech stack and personalities involved, this can become a pretty serious debate.
I have no intention whatsoever of wading into the middle of that debate here today. Rather, I’d like to tackle this subject from a slightly different angle. Let’s take at face value that text editors are comparably feature-poor but nimble, and that IDEs are comparably feature-rich but laden with abstraction. Framed as a tradeoff, then, it becomes clear that realizing the benefits of one choice is critical for justifying it. To put it more concretely, if you’re going to incur the overhead of an IDE, then it had better be doing you some good.
With this in mind, what should you expect from an IDE? What should it do in order to justify its existence, and what should be a deal breaker if missing? Let’s take a look at what’s reasonable to expect from IDEs.
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, download a trial of NDepend and give it a spin.
I do a lot of work with and around static analysis tools. Obviously, I write for this blog. I also have a consulting practice that includes detailed codebase and team fact-finding missions, and I have employed static analysis aplenty when I’ve had run of the mill architect gigs. Doing all of this, I’ve noticed that the practice gets a rap of being just for techies.
Beyond that even, people seem to perceive static analysis as the province of the uber-techie: architects, experts, and code statistics nerds. Developing software is for people with bachelors’ degrees in programming, but static analysis is PhD-level stuff. Static analysis nerds go off, dream up metrics, and roll them out for measurement of developers and codebases.
This characterization makes me sad — doubly so when I see something like test coverage or cyclomatic complexity being used as a cudgel to bonk programmers into certain, predictable behaviors. At its core, static analysis is not about standards compliance or behavior modification, though it can be used for those things. Static analysis is about something far more fundamental: furnishing data and information about the codebase (without running the code). And wanting information about the code is clearly something everyone on or around the team is interested in.
To drive this point home, I’d like to cite some examples of less commonly known value propositions for static analysis within a software group. Granted, all of these require a more indirect route than, “install the tool, see what warnings pop up,” but they’re all there for the realizing, if you’re so inclined. One of the main reasons that static analysis can be so powerful is scale — tools can analyze 10 million lines of code in minutes, whereas a human would need months.
Editorial note: I originally wrote this post for the LogEntries blog. You can check out the original here, at their site. While you’re there, sign up for the service and check it out.
It seems almost strange to talk about avoiding things while logging. After all, logging is your last line of defense or your salvation in many cases. Some crazy bug in the field that shows up every third full moon? An external auditor looking at your app’s runtime behavior? Logging to the rescue.
So naturally, is stands to reason that you would want to log just about everything your application. Whenever there’s any doubt, slam a logger call in there and let log level sort out the details. You can always filter logs, but you can’t magic stuff into them after the fact. So why, then, talk of avoidance?
Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems. You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it. You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.
So what are these problems, and how to avoid them? Let’s take a look at some things that can come back to bite you.