To this day, I have a persistent nightmare about my time in college. It’s always pretty similar. I wake up and I have a final exam later in the day, but I’m completely unprepared. And I don’t mean that I’m unprepared in the sense that I didn’t re-read chapter 4 enough times. I mean that I realize I haven’t attended a single lecture, done a single homework assignment, or really even fully understood what, exactly, the course covers. For all intents and purposes, I’m walking in to take the final exam for a class I haven’t taken. The dream creates a feeling that I am deeply and fundamentally unprepared for life.
I’ve never encountered anything since college that has stuck with me quite as profoundly; I don’t dream of being unprepared for board meetings or talks or anything like that. Perhaps this is because my brain was still developing when I was 20 years old, or something. I’m not a psychologist, so I don’t know. But what I do know is that the closest I came to having this feeling was in the role of software architect, responsible for a code base with many contributors.
If you’re an architect, I’m sure you know the feeling. You’ve noticed junior developers introducing global variables on a few occasions and explained to them the perils of this practice, but do you really know they’re not still doing it? Sure, you check from time to time, but there’s only one of you and it’s not like you can single-handedly monitor every commit to the code base. You do like to go on vacation at least every now and then, right? Or maybe you’ve shown your team a design pattern that will prevent redundancy and standardize what had been a hodgepodge approach. You’ve monitored the situation for a few commits and noticed that they’re not getting it quite right, but you can live with what they’re doing… as long as it doesn’t get any further off the rails.
You get the point. After all, you’re living it. You don’t need me to tell you that it’s stressful being responsible for the health of a code base that’s changing faster than you can track in any level of detail. If you’re anything like me, you love the role, but sometimes you long for the days when you were making your presence felt by hacking things and cranking out code. Well, what if I told you there were a way to get back there while hanging onto your architect card… at least, to a degree?
You and I both know it — you’re not going to be spending 8+ hours a day working on feature implementations, but that doesn’t mean that you’re forever consigned to UML and meetings and that your hacking days are completely over. And I’m not just talking about side projects at night. It’s entirely appropriate for you to be writing prototyping code and it’s also entirely appropriate for you to write little plugins and scripts around your build that examine your team’s code base. In fact, I might argue that this latter pursuit should be part of your job.
What do I mean, exactly, by this? What does it mean to automate “examining your team’s code base?” You might be familiar with this in its simplest forms, such as a build that fails if test coverage is too low or if there are compiler warnings. But this concept is extremely extensible. You don’t need to settle for rudimentary information about your team’s code.
NDepend is a tool that provides you with a lot of information out of the box as well as hooks with which to integrate that information into your team’s build. You can see architectural concerns at a high level, such as how much you depend on external libraries and how internally coupled your modules are. You can track more granular concerns such as average method complexity or class cohesion. And you can automatically generate reports about these things, and more, with each build. All of that comes built in.
But where things get really fun and really interesting is when you go beyond what comes out of the box and start to customize for your own, specific situation. NDepend comes with an incredibly powerful feature called CQLinq that lets you ask very custom, specific questions about your code. You can write a query to see how many new global variables your team is introducing. You can see if your code base is getting worse, in terms of coupling. And, you can even spend an afternoon or two putting together a complex CQLinq query to see if your team is implementing the pattern that you prototyped for them.
And not only can you see it — you can see it in style. You can generate a custom report with clear, obvious visuals. This sort of visualization isn’t just decoration. It has the power to impact your team’s behavior in a meaningful way. They can see when their checkins are making more things green and happy and when their checkins are making things red and angry. They’ll modify their code accordingly and basically anonymously, since this feedback is automated. They’ll like it because automated feedback won’t feel judgmental to them, and you’ll like it because you’ll know that they’re being funneled toward good architectural decisions even when you aren’t there. Talk about peace of mind.
You’ll spend a few days getting to know NDepend, a few days tweaking the reports out of the box, and a few days hacking the CQLinq queries to guard your code base according to your standards. And, from there on in, you’ll enjoy peace of mind and be freed to focus on other things that command your attention. As an architect there are a thousand demands on your time. Do yourself a favor and get rid of the ones that you can easily automate with the right tooling.
Comments:
Comments are closed.