Should you TDD when flying solo?

A couple of weeks ago a question came up on the ALT.NET message board:

Does TDD make sense when you’re the only developer in your company?

To me, this is akin to the following questions:

  • Is quality important?
  • Is maintainability important?
  • Is design important?

Remember, TDD is all about design.  Unit tests are icing on the cake.  TDD shows me where I violate the Dependency Inversion Principle.  TDD shows me if my design makes sense from the client’s perspective.  TDD encourages low coupling and high cohesion (but doesn’t guarantee it).  TDD gives me immediate visibility into the pain points of my system.  TDD gives me confidence that my design is right.  TDD gives me confidence to refactor carefully or recklessly.

Without TDD, I have zero confidence in my design is both what I intended nor what is needed.  Without client code exercising concrete behavior for explicit contexts, I have no visibility into the “why” of the design.  Without TDD, I’m flying completely blind.  I can draw UML diagrams, sketch out code, even write little test applications.  But unless I can demonstrate behavior in specific contexts, I have no evidence that my design is right.

Now pair programming solo, that requires some extreme dexterity…

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • There is a lot of discipline that goes into TDD,though. I’m not sure I’d advise people to start TDD by themselves. Find a friend and pair for a few hours on a saturday to learn the fundamentals and then go forth and conquer. Be constantly aware that you’re probably doing something wrong and you need to re-evaluate often and find your pain and seek out guidance to help resolve it.

    If testing gets hard and you have to force yourself, you’re doing it wrong and you should stop and call in your friends.

  • Erik

    @chadmyers: Suppose you don’t have any friends in the industry? I *have* to go it alone – I don’t know anybody local to me to help, and none of the programmers I do know are familiar with TDD either. =(

  • I don’t have any friends in the industry either (unless you consider Jimmy Bogard, but with friends like him, who needs enemas?).

    Seriously though, two guys not knowing how to do TDD but pairing and trying to work though it is better than nothing, because then you can get encouragement and someone to say “This way we’re doing it sucks, let’s try something else”

    Where are you geographically? Do you have decent bandwidth, we could do a remote pairing session. It’s not very good, but it’s better than nothing.

    Worse comes to worse, a phone or skype call with someone would be helpful. If you’re interested, contact any of the Los Techies guys and we can try to get something set up for you.

    Also, depending on where you’re at, we might know some people or be able to help put a shout-out for you to help you get connected with people who can help locally.

  • Hence, do TDD. LOL to your last statement. Certain states of schizophrenia may help – depending on your alter egos ;)

  • DannyBhoy

    How about “Does TDD make sense when you are the only developer in the company… who sees any value in TDD”?

    I’ve been told I’m wasting time, going against established (and agreed failing!!) practices, “showing off the latest fad I’ve ripped from someone’s blog”, writing too much code, refactoring too much so there’s too many changes in the commits, etc. You can maybe put up with that, but then wait until you go back to find all your tests failing because they are not even maintaining the tests that are there.

    Working on my own sounds like paradise compared to that…

  • @Danny

    Don’t worry, I don’t know a TDD practitioner that hasn’t gone through the same scenario. Getting buy-in from management for agile practices is hard enough, getting buy-in from teammates can be even harder.

    The documented benefits of unit tests, automated builds and refactoring are pretty extensive. I convinced my last company by putting together a short presentation, showing monetary loss for _not_ doing these practices. Bugs found after release are orders of magnitude more expensive than found during nightly automated testing.

    Fear can be a great barrier to overcome when trying new things.

  • Erik

    @chad – geographically, near Charleston SC. Never done the pair programming bit, so I’m not sure how it’d work local or remote, but I’d be willing to give it a try. Bandwidth is ‘ok’ – VNC on low quality settings works decently for me when I’m away from the house.

  • @Erik (or anyone, really):

    Contact me at

    Remove the extraneous z’s and dots (sorry, it’s to block spammers).

  • Reshef Mann


    Try to take a look here:–Episode-1-Rhino-Mocks-101.aspx

    This is a webcast by ayende which I found very useful when I started investigating TDD.

  • Erik

    Thanks Reshef =) I’ll check it out – I can use all the help I can get! =P