Why TDD?

Two days ago I read the article Why TDD by Matthew Kane Parker and I really enjoyed both the article and accompanying video. That said, I have a small disagreement with the content that Matt asked me to clarify after my tweet.

Matthew puts forth the assertion that our goal is to 'Go Fast, Forever'. I'm not so sure about that. The goal, in my mind, is to delivery value; to make or save money as an over simplification. I'm probably picking nits here, but going fast is part of the iron-triangle under the goal of value delivery and forever implies that there is no end to our task. Practically speaking there must be an end to our task, and it is one that we can realistically predict; when the cost of development/maintenance exceeds some percentage of the future return on investment, we stop.

So, how does this relate to TDD. I completely agree that TDD enables speed and helps assure quality and correctness, however, The Essence of TDD is to attain an understanding of what needs to be done, the rest of it is a happy coincidence. 

So, if our goal is to deliver value, we need to understand how that value manifests itself, then what to build that delivers on that. We need to understand what needs to be done to achieve that goal, and we do that through TDD (and other things). 

So consider that tests on the outside of the system prove that the manifestation of value is present, while tests interior to or specifically about the system express the understanding of the 'what', ideally in terms of behavior, that delivers the value. TDD enables the development of the understanding and coincidentally provides other benefits like regression testability, design pressure, safe refactoring, etc. 

Don't get me wrong, the later all all great things, and TDD is likely the very best way to get them; but it isn't the only way. TDD, however, is the most direct way to develop a understanding of the system incrementally. 

ps - Matthew has written a number of articles that I would recommend you check out, specifically Four Goals of a Good Test Suite. 

A One Liner to Collect Your Python Deps

So I had a need to collect the name, version, and license info for all of my applications dependancies. I sought out and tried a few open/free tools but could not get what I needed from them (many just didn't work).

I crafted this bash-one-liner to solve my problem;

The results look like this;

adal 0.5.0 MIT
appnope 0.1.0 BSD
args 0.1.0 BSD
asn1crypto 0.24.0 MIT
astroid 1.6.1 LGPL
attrs 17.2.0 MIT

I hope this can help someone else too.

Mob Programming Anti-Pattern?

One of the teams I'm working on is using mob programming. I think I've identified an anti-pattern here. Mobbing can devolve into something akin to Brook's Surgical Team. 

Sometimes, you end up with one mobster who's driving everything. It's as if nobody else is required. The only way you know it's still a mob is that this mobster isn't typing, they are telling someone else what to type. 

I'm not talking about someone who just provides direction for a short while, I'm talking about 'all day'. What's worse is, at the end of the day it seems like nobody complains. 

Mobbing takes some discipline. You have to push back when someone acts like this; speak up in retro. If they won't change their behavior, leave the mob. Eventually they will just be working on their own.