Stories about Software


Get Good at Testing Your Own Software

There’s a conventional wisdom that says software developers can’t test their own code.  I think it’s really more intended to say that you can’t meaningfully test the behavior of software that you’ve written to behave a certain way.  The reasoning is simple enough.  If you write code with the happy path in mind, you’ll always navigate the happy path when testing it, being hoodwinked by a form of confirmation bias.

To put it more concretely, imagine that you write a piece of code that reads a spreadsheet, tabulates sums and averages, and reports these to a user.  As you build out this little application, one of the first things you’ll do is get it successfully reading the file so that you can write the other parts of the application that depend on this prerequisite.  Over the course of your development, you’ll be less likely to test all of the things that can go wrong with reading the spreadsheet because you’ll develop kind of a muscle memory of getting the import right as you move on to test the averages and sums on which you’re concentrating.  You won’t think, “what if the columns are switched around” or “what if I pass in a Word document instead of a spreadsheet?”

Because of this effect, we’re scolded not to test our own software.  That’s why QA departments exist.  They have the proper perspective and separation so as not to be blinded by their knowledge of how things are supposed to go.  But does this really mean that you can’t test your own software?  It may be that others are more naturally suited to do it, but you can certainly work to reduce the size and scope of your own blind spot so that you can be more effective in situations where circumstances press you into testing your own code.  You might be doing a passion project on the side or be the only technical member of a startup – you won’t always have a choice.

Let’s take a look at some techniques that will help you be more effective at testing software, whether written by you or someone else.  I originally wrote this post for the Infragistics blog, so click here to read about the techniques to which I’m referring.


A Test Coverage Primer for Managers

Managing Blind

Let me see if I can get in your head a little bit.  You manage a team of developers and it goes well at times.  But, at other times, not so much.  Deadlines slide past without a deliverable, weird things happen in production and you sometimes get deja vu when a bug comes in that you could swear the team fixed 3 months ago.

What do you do?  It’s a maddening problem because, even though you may once have been technical, you can’t really dive into the code and see what’s going on.  Are there systemic problems with the code base, or are you just experiencing normal growing pains?  Are the developers in your group painting an accurate picture of what’s going on?  Are they all writing good code?  Are they writing decent code?  Are any of them writing decent code?  Can you rely on them to tell you?

As I said, it’s maddening.  And it’s hard.  It’s like coaching a sports team where you’re not allowed to watch the game.  All you can do is rely on what the players tell you is going on in the game.

A Light in the Darkness

And then, you light upon a piece of salvation: automated unit tests.  They’re perfect because, as you’ll learn from modern boilerplate, they’ll help you guard against regressions, prevent field defects, keep your code clean and modular, and plenty more.  You’ve got to get your team to start writing tests and start writing them now.

But you weren’t born yesterday.  Just writing tests isn’t sufficient.  The tests have to be good.  And, so you light upon another piece of salvation: measuring code coverage.  This way, not only do you know that developers are writing tests, but you know that you’re covered.  Literally.  If 95% of your code base is covered, that probably means that you’re, like, 95% good, right?  Okay, you realize it’s maybe not quite that simple, but, still, it’s a nice, comforting figure.

Conversely, if you’re down at, say, 20% coverage, that’s an alarming figure.  That means that 80% of your code is not covered.  It’s the Wild West, and who knows what’s going on out there?  Right?  So the answer becomes clear.  Task a team member with instrumenting your build to measure automated test coverage and then dump it to a readout somewhere that you can monitor.

Time to call the code quality issue solved (or at least addressed), and move on to other matters.  Er, right?

I originally wrote this post for the NDepend blog.  Click here to read the rest.


Getting a Card’s Info From Trello

One of my absolute favorite all time tools is Trello, which is essentially a web application that digitizes the kanban board.  As a Trello user, you have one or more boards, and each board can have one or more columns.  In each column, there are cards.  And, like a live kanban board, you can move the cards around between columns.

Trello is good enough to expose a RESTful API so that I can interact easily with it.  I’m not going to go into a lot of detail on the particulars of the REST style of architecture here, as that’s not my main purpose.  But I will offer the useful way of thinking about REST that it’s an idea of pairing identified resources with actions — specifically, HTTP actions.  Or, more simply, it’s the idea of pairing nouns and verbs.  And so, figuring out who the members of the Beatles were might involve making a GET request to http://somesite/music/beatles while adding myself to the Beatles might mean issuing a PUT request to http://somesite/music/beatles with a JSON payload containing my name.  Pretty awesome, huh?  I’ve always wanted to be a Beatle.

Alright, so let’s use this REST API from Trello to get a card out.  Trello offers a “getting started” tutorial, and that got the job done for me, but I think it could be explained more simply.  They’re aiming to get you started writing applications that interoperate in rich ways with their web application, but I’m just interested, for now, in getting back “toothbrush.”

To understand what I mean, take a look at the screenshot below from one of my Trello boards, “Packing.”  I use this board when preparing for trips.  I populate the “pack” column with stuff to put in my suitcase, “non-suitcase” with stuff like my laptop and Kindle, and “To Do” with things like “set the thermostat” or “water the plants.”  What I want to do here is thus dead simple.  I want to get ahold of that toothbrush card via their API.  That’s it.


To do this, you need to be logged in to Trello and, obviously, you’re not going to have my toothbrush card, but you can create your own board and card to follow along.  Do that now, if you like.

Once you’ve identified a card for which to do this, you’re going to need three things: the id of the card, an “application key,” and a “token.”  What you’re not going to need is to open Visual Studio or any other IDE, nor will you need to figure out some kind of REST client to build your request.  You’ll do just fine with your browser, as-is.  We’ll get to the REST clients and IDEs in future posts.

What was initially confusing when you’re reading their “getting started” page is why you need a key and a token.  Well, the key is for you as a Trello developer, whereas the token is your way of authorizing calls to your non-public boards (and most boards aren’t public).  To make it easier to understand, I could use my developer key to query Trello’s public development board and I could also use it to access Ringo Starr’s private boards if Ringo Starr issued me a token allowing this.  So when it comes to querying my own board, I need a developer key, and I also need to grant myself permission with a token.

Make sense?  Good.

Now, to get down to business.  Navigate to the trello app-key page while logged in and you’ll be granted your key at the top.  That’s the easy part.  To grant yourself a token, you’re going to need to work.  Scroll down to the bottom and click on the link that says “Click here to request a token to be used in the example.”


Once you click that, you’ll get a pop-up requesting permission to grant the application access to use your account.  Hopefully this drives home the idea of a token.  In general, if you want anything to be able to interact with your Trello account, you have to give it permission via this token.  Once you’ve done that for your own account, it’s time to rock and roll.  Now all you need is the ID of the card that you’ve created, which you can get just by clicking on the card through the application, like so.


With that id in hand, type the following into your URL bar making appropriate substitutions for the placeholders that are colored orange:


You should see a bunch of JSON in your browser, outlining the attributes of this card.


And that’s it.  Without code, IDE or tools beyond the browser, you’ve successfully used Trello’s API.  

This was a post that I originally wrote for Infragistics, and you can find it here.  Check out their site for the rest of the posts in this series, where I actually go through building a page using IgniteUI and the Trello API to build a little, client side utility that shows you cards and their due dates.


Don’t Learn to Code — Learn to Automate

Does anyone remember a few years ago, when the mayor of New York decided to learn to program? It was a heady time, because it wasn’t just him. I remember these surreal commercials where Miami Heat forward Chris Bosh was encouraging children to learn to code for the good of humanity or something. There was this sudden, overwhelming sentiment that humanity should abandon the folly of any non-programming pursuit and learn them some Ruby or whatever. Andy Warhol, were he alive in 2012, no doubt would have said, “in the future, everyone will write code for 15 minutes.”

Jeff Atwood wrote an interesting rebuttal to this zeitgeist, entitled, “Please Don’t Learn to Code.” The covers a good bit of ground and makes some interesting points, but the overarching thesis seems to be, “avoid thinking of writing code as the goal and learn to solve problems.” I think this is an excellent, philosophical point, but I’d like to add a bit of nuance.

I’ve written in the past about how important I think that it is to be a problem solver, to the point where I wrote a post about liking the title “problem solver.” So please don’t think I disagree with his take that a lot of programmers get too hung up with the particulars of code. I don’t — I think that’s a very common issue. But, at the same time, I think the mayor of New York and Chris Bosh and others have a point that Jeff doesn’t really address, per se. Specifically, the world is getting dramatically more technical, which means that a lot of pursuits are being automated out of existence, while other pursuits require an increasing degree of technical savvy. My fiancee, a professional copy editor, is finding aspects of her job to be easier if she knows a bit of HTML and CSS.

So while I wince alongside Jeff at the thought of people randomly learning programming languages because they think it’ll make them rich or because they want to be a person that writes lots of code, I don’t think we can simply say, “stay out unless you’re serious and willing to spend years getting good.” The rapidly evolving technical landscape has created this black hole of technical savvy that’s sucking in even people well past the event horizon.

The advice that I’d offer on this subject creates a pretty fine distinction. I don’t think that everyone needs to learn to code by any stretch. What I think that everyone needs to start learning about and understanding is how to automate. Or, if not how to do it themselves, at least how to recognize things that could be automated and have meaningful discussions about whether the effort is worth it or not. Read More


Improving Your Craft with Static Analysis

These days, I make part of my living doing what’s called “software craftsmanship coaching.”  Loosely described, this means that I spend time with teams, helping them develop and sustain ways to write cleaner code.  It involves introduction to things like the SOLID Principles, design patterns, DRY code, pair programming, and, of course, automated testing and test driven development (TDD).  I’ve spent a lot of time contemplating these subjects and their economic value to organizations, even up to the point of creating a course for Pluralsight.com about this very thing.  And through this contemplation, I’ve come to realize that TDD is an extraordinarily nuanced practice, both in terms of advantages offered and challenges presented.

This post is not about TDD, so what I’d like to do is zoom in on one particular benefit offered by the practice.  It’s a benefit that tends to be overlooked beside the regression suite that it generates and the loosely coupled design that it encourages.  But one of the important things that TDD does is to provide a very tight, automated feedback loop.  Consider what generally happens if you’re working on a web application and you want to evaluate the effects of your most recent changes to the code base.  You build the code and then run it, and running it is generally accomplished by deploying it to some local version of a web server and then starting the web server.  Once the web server and your web application are running, you then engage the GUI and navigate to wherever it is that will trigger your code to be run.  Only at this point do you get feedback about what you’ve done.  TDD short-circuits this process by requiring only build and execution of a test suite.

Of course, TDD isn’t the only way to create a tight feedback loop, but it is a well recognized one.  And it’s also one that tends to spoil you.  After becoming used to TDD, it’s hard to go back to waiting for long cycle times between writing code and seeing the results.  In fact, it tends to go the other way and you find yourself chasing other means of obtaining fast, automated feedback.  It was this exact dynamic that got me hooked on the idea of static code analysis.  If I could get quick feedback from unit tests about whether my code worked, why couldn’t I get feedback about whether it was well written?

Read More