Stories about Software


Is Your Code Hard to Understand?

Editorial Note: I originally wrote this post for the Infragistics blog.

I’ve heard a bit of conventional wisdom in the software industry.  It holds that people will read a given line of code an order of magnitude more times than they’ll modify it.  Whether that wisdom results from a rigorous study or not, I do not know. But it certainly squares with my experience.  And it also seems to square with the experience of just about everyone else.

Accepting this wisdom as axiomatic, code readability becomes an important business concern.  If you optimize for ease of writing at the cost of ease of reading, your business will lose money.  Better to spend some extra time in writing your code to ensure that future readers have an easy go of it.  And easy for them means that they understand the code.

You know of obvious ways to promote reader understanding in code.  Don’t give variables cryptic names or names that cannot be pronounced.  Don’t write gigantic methods and classes.  Limit method parameters and local declarations.  Read through the code out loud to see if it seems clear.  These guidelines will bring you a long way toward readability.

But other, subtle concerns can also chip away at your code’s readability.  I’ll list some of these here, today.  These are generally C# specific, but some are more broadly applicable than that.  What all of them have in common is that they constitute sources of confusion for readers that may not seem immediately obvious.

Read More


Managing Code Analysis Statistics with the NDepend API

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  Also, NDepend just released a new version that addresses tech debt extensively — check it out while you’re there!

If you’re familiar with NDepend, you’re probably familiar with the Visual Studio plugin, the out of the box metrics, the excellent visualization tools, and the iconic Zone of Uselessness/Zone of Pain chart.  These feel familiar to NDepend users and have likely found their way into the normal application development process. NDepend has other features as well, however, some of which I do not necessarily hear discussed as frequently.  The NDepend API has membership in that “lesser known NDepend features club.”  Yes, that’s right — if you didn’t know this, NDepend has an API that you can use.

You may be familiar, as a user, with the NDepend power tools.  These include some pretty powerful capabilities, such as duplicate code detection, so it stands to reason that you may have played with them or even that you might routinely use them.  But what you may not realize is the power tools’ source code accompanies the installation of NDepend, and it furnishes a great series of examples on how to use the NDepend API.

NDepend’s API is contained in the DLLs that support the executable and plugin, so you needn’t do anything special to obtain it.  The NDepend website also treats the API as a first class citizen, providing detailed, excellent documentation.   With your NDepend installation, you can get up and running quickly with the API.

Probably the easiest way to introduce yourself is to open the source code for the power tools project and to add a power tool, or generally to modify that assembly.  If you want to create your own assembly to use the power tools, you can do that as well, though it is a bit more involved.  The purpose of this post is not to do a walk-through of setting up with the power tools, since that can be found here.  I will mention two things, however, that are worth bearing in mind as you get started.

  1. If you want to use the API outside of the installed project directory, there is additional setup overhead.  Because it leverages proprietary parts of NDepend under the covers, setup is more involved than just adding a DLL by reference.
  2. Because of point (1), if you want to create your own assembly outside of the NDepend project structure, be sure to follow the setup instructions exactly.

A Use Case

I’ve spoken so far in generalities about the API.  If you haven’t already used it, you might be wondering what kinds of applications it has, besides simply being interesting to play with.  Fair enough.

One interesting use case that I’ve experienced personally is getting information out of NDepend in a customized format.  For example, let’s say I’m analyzing a client’s codebase and want to cite statistical information about types and methods in the code.  Out of the box, what I do is open Visual Studio and then open NDepend’s query/rules editor.  This gives me the ability to create ad-hoc CQLinq queries that will have the information I need.

But from there, I have to transcribe the results into a format that I want, such as a spreadsheet.  That’s fine for small projects or sample sizes, but it becomes unwieldy if I want to plot statistics in large codebases.  To address this, I have enlisted the NDepend API.

Read More


Logging the Lights in Your Home

Editorial Note: I originally wrote this post for the LogEntries blog.  You can find the original here, at their site.  While you’re there, check out the log aggregation service they offer and see if you could use some help storing and querying your log files.

It’s all the rage these days under the general heading of “Internet of Things” (IoT), but I have been a home automation enthusiast for more than 10 years now.  In the interceding time, I’ve done experiments and written about the subject.  I even published a Pluralsight course, in which I turned a Raspberry Pi into a RESTful server that lets you turn lights in your house on and off using basic X10 technology.  You can certainly say I have a lot of experience, both with newer techs and comparably archaic ones.

Because I’ve been in the game so long, you might think that I’m a strict constructionist, if you will, wanting to build everything myself from raw parts.  But I’m not.  Even though I enjoy assembling these systems from their components, I am a fan of the strides made by various vendors over the years, and I’m thrilled to see different players enter the space and expand home automation mind share in the general public.  In fact, I’m excited as a technologist that I can leverage already-assembled techs and services to achieve my home automation goals.

Introducing Wink

Against this backdrop, my mom recently gave me a Wink hub and companion lights for my birthday.  Wink is a service that does what I once quixotically sought to do in my spare time on weekends: it unifies disparate smart devices to allow centralized control over them.  The hub is synced with the Wink service in general, allowing control from anywhere, and the hub communicates over house Wifi with the satellite devices.  I can now turn on a couple of lights from anywhere in the world, with the workflow occurring as follows.

  1. I pop out my phone while vacationing somewhere sunny, open the Wink app, and tell it to turn on my master bedroom light.
  2. The Wink app phones home to the wink servers, communicating this request.
  3. The Wink servers pass the message on to my connected Wink hub at home.
  4. The Wink hub relays the message over Wifi to the light, which turns on.

It’s really pretty slick.  It also causes me a wry smile of amusement, since I just got a birthday gift that does out of the box something I worked for months to make happen.  But then I trade that smile for a genuine one when I think about how much more I can do in this landscape.

Read More


Avoid these Things When Logging from Your Application

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.

Read More


Keeping Your Code Clean while Logging

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, take a look at their product offering that handles your log aggregation, search, and alerting needs.

In my consultancy practice, one of the things that I do most frequently is help teams write so-called “clean code.”  Usually, this orients around test-driven development (TDD) and writing code that is easily maintained via regression tests and risk-free refactoring.  Teams want to understand how to do this, and how to do it in their production code (as opposed to in some kind of toy “let’s build a calculator” exercise).


One of the most prominent, early sticking points that rears its head tends to be application logging.  Why?  Unit testing is all about isolating objects, instantiating them, and rapidly verifying their behavior in memory.  Logging is all about dumping as much information as possible to a file (or database, service, etc with appenders) from as many places as possible.  Unstoppable force, meet immovable object.

For instance, consider the following C# code from a “let’s build a calculator” exercise.

Life here is good.  The calculator’s add method returns the sum of the integers, and we have a test method that supplies 2 and 2, and confirms a result of 4.  That’s a screaming fast, very clear test.  But, consider what happens if we amend our calculator to take advantage of logging.

Now, with that same test, everything goes wrong.  Instead of passing, it throws an exception about not having write access to some weird directory on your machine that you’ve never even heard of.  After digging a bit, you see that it’s the directory in which the test runner executes when running your solution’s tests.  Hmmm.

Read More