Stories about Software


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


4 Ways Custom Code Metrics Make a Difference

Edit: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try.  If you like static analysis, you’ll find yourself hooked.

One of the things that has surprised me over the years is how infrequently people take advantage of customizable code metrics.  I say this not from the perspective of a geek with esoteric interest in a subject, wishing other people would share my interest.  Rather, I say this from the perspective of a business man, making money, and wondering why I seem to have little competition.

As I’ve mentioned before, a segment of my consulting practice involves strategic code assessments that serve organizations in a number of ways.  When I do this, the absolute most important differentiator is my ability to tailor metrics to the client and specific codebases on the fly.  Anyone can walk in, install a tool, and say, “yep, your cyclomatic complexity in this class is too high, as evidenced by this tool I installed saying ‘your cyclomatic complexity in this class is too high.'”  Not just anyone can come in and identify client-specific idiosyncrasies and back those findings with tangible data.


But, if they would invest some up-front learning time in how to create custom code metrics, they’d be a lot closer.

Being able to customize code metrics allows you to reason about code quality in very dynamic and targeted terms, and that’s valuable.  But you might think that, unless you want a career in code base assessment, that value doesn’t apply to you.  Let me assure you that it does, albeit not in quite as direct way as it applies to me.

Custom code metrics can help make your team better, and they can do so in a variety of ways.  Let’s take a look at a few.

Read More


Code Review Beyond Meeting Rooms and Projectors

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re over there, have a look at their Collaborator offering.

It must have been a decade ago.  I was sitting in a spaciously appointed conference room around a large, round table, surrounded by fellow software developers from my company.  Coffee and bright lights notwithstanding, we were all struggling to varying degree to keep alert.

The reason for our struggle was that we were spending the day doing a marathon code review, and we were barely halfway through the morning.  A representative of the team that had written the code was on hand, walking us through it, showing the code against a pull down screen with a projector.  We were being treated to file after file after file, in alphabetical order, in a text editor.

There were hours of this yet to go.  And yet, it was an unavoidable matter of due diligence.  In spite of our wandering attention spans, we believed this, as did our management.  Our company had contracted with a custom software vendor to write an application that our company would take over and maintain.  This firm had scurried off for 9 months or so, and they were now presenting “phase 1” to us.  This was our chance to raise concerns and provide input.  Theoretically, anyway.


As you can imagine, this was not an especially effective way to spend a day (or several, as it would turn out).  We technically saw all of the code that was being delivered, but it wasn’t as though this activity produced a lot of meaningful output.  There were some obvious reasons for this, such as the enormous batch of reviewing 9 months of code and the marathon, all-in nature of the session.  But there were also some issues related to tooling and process that were pretty limiting compared to what we have now.

10 years have elapsed since this yawn-inducing series of days I spent in review.  And, while you’re still going to be in trouble if you try meaningfully to review 9 months of a team’s code in a few days, tools and workflows have emerged in the interceding years that make code review much easier.  You should be taking advantage of them.

Read More


Undercover Testability Killers

Editorial Notes: I originally wrote this post for the Infragistics blog.  You can check out the original here, at their site.  While you’re there, take a look around at the other posts by their contributing authors.

If you were to take a poll of software development shops and ask whether or not they unit tested, you’d get varied responses.  Some would heartily say that they are, and some would sheepishly say that they totally mean to get around to that next year and that they’ve totally been looking into it.  In the middle, you’d get a whole lot of responses that amounted to, “it’s complicated.”

In my travels as a consultant, I witness the reason for this firsthand.  The adoption rate of automated testing has increased dramatically in the last decade, and that increased adoption means that a lot of shops are taking the plunge.  And naturally, this means that a lot of shops with a lot of legacy code and awkward constructs in their codebases are taking the plunge, which leads to interesting, complicated results.


It’s Complicated

“It’s complicated” generally involves variants of “we tried but it wasn’t for us” and “we do it when we can, but the switch hasn’t flipped yet.”  And, at the root of all of these variants lies a truth that’s difficult to own up to when talking about your group – “we’re having trouble getting any good at this.”

If this describes you or folks you know, take heart, though.  The “Intro to TDD” and “NUnit 101” guides make it look really, really easy.  But those sources of learning usually show you how to write unit tests for things like “in-memory calculator,” intending to simplify the domain and code so that you understand the mechanics of a unit test.  But, in doing this, they paint a deceptive picture of how easy covering your code with tests should be.

If you’ve been writing code for years with nary a thought to testing at the unit level, it’s likely that familiar, comfortable coding practices of yours are proving to be false friends.  In other words, your codebase is probably littered with things that are actively making your life extremely difficult as you try to adopt automated testing.  What follows are some of the most common ones that I see.

Read More