16 March 2018

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

07 March 2018

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.

15 November 2017

Architects in an Agile/Lean World

I just read this very nice post from Martin Fowler on The Role of an Enterprise Architect in a Lean Enterprise. He has a lot of good thoughts in there. 

I submit that there is one aspect lacking emphasis in this post however, the responsibility of the agile team to interact with the architect. That is, agile or not, architecture is still a thing in every organization. At some time, some person made a variety of choices about how systems should be structured, interconnected, and in some cases to be implemented. 

Those decisions were not made lightly or in a vacuum and often the consequences of changing them have far reaching consequences that may not be apparent to those without knowledge of the entire enterprise system. Consider that an architects job among other things is to deliver value to the business over an extended period of time. Part soothsayer, part Oracle, an architect should be working to further enable business objectives through technology, not just in the near term, but for the foreseeable future of the organization. 

Architects, like everyone else, are fallible human beings and they cannot foresee every circumstance. Any given project may run afoul of gaps in a generalized architecture or may struggle to integrate two technologies due to any number of compatibility factors. These are times when an agile/lean team should be reaching out to the architect for help. As Martin points out, part of the architects job is not to say 'No' but to make sure the team is fully aware of the consequences of deviations from the current technology stack. 

Failure to consult with the architect when these decision points are reached is just plain negligence. Furthermore, failure of the architect to respond and cooperate with the team is a gross dereliction of duty. Like everything else in the agile/lean world, the relationship is a partnership with a shared goal and it is incumbent on all parties to participate in that partnership; to cooperate to find solutions.

06 November 2017


I spent most of my weekend working on my NaNoWriMo book. If you aren't familiar with NaNoWriMo, the idea is to write 50,000+ words in a month, basically a novel. The degree to which you prepare for this event is entirely up to you. I've been talking about what I would write about since July, but I haven't really developed the details. 

So, I'm trying to write about gang members in Mexico, but I don't have a town name, a general description of the town, etc. I haven't even named the gang. Its all pretty vague.

So the problem with that is, nothing in the descriptions is named. Or if it is, it's in general terms. The Pontiac. The Boulevard. The Restaurant. Obviously, those are details I'll need to go back and fill in at some point. 

I've witnessed a parallel in project teams. Teams where an idea is discussed, changing the messaging infrastructure for example. The idea is discussed periodically in non-specific terms over an extended period of time, but there are never any details. 

Two things tend to happen. Often, because there is nothing concrete, the work never happens; it remains a goal that is unachieved. The other is, the work is attempted, but it is a horrid mess of a change because there wasn't agreement about the 'how and the what'. 

Don't get me wrong, I'm all for late binding on the 'how and what', but that ultimately has to happen. There should be a progression of work toward that 'how and what', maybe a series of spikes to prove or disprove things about the intended approach, but those need to be focused a little. Someone, someplace, has to provide a specific objective or set of criteria in order to focus the work.

There are a number of ways to get there. The Architect, as a technical product owner, can specify a set of behaviors required of the system. The Tech Lead could specify an approach, either in how the interaction should work, or even some specifics about the tool. The Director of Engineering might also have requirements about cost, platform selection, etc. Without these hints and nudges a team could drift aimlessly trying to make the change happen. 

One last thing that is essential. The work has to get scheduled. It won't just happen in between other cards on the board. The product management team must make a change important and schedule it; set a goal date for completion, or otherwise do something to cause the work to happen. Even if a development team agrees upon the importance of a change, they are beholden to the planned work. If it isn't on the schedule, it just wont happen.

03 November 2017


I live in a microcosm. 

So last week I went to SCNA and talked to a bunch of people there that I don't talk to enough. I've also been having lots of conversations about How it Should Be Done™

So many of the people I've been working with over the past 10 years or so have very similar back grounds, have read the same books and white papers, and worked in the same environments. There is a significant degree of group-think involved. 

Recently though, I've been exposed to some new people who don't have those characteristics, or rather, come from a different group. I'm learning a lot about how other people think about problems and I'm learning a lot about how other people think. 

I don't agree with some of the things I'm learning; which is to say, I've learned a few new techniques and ways of looking at problems and I don't agree that they are more effective or better than what I was already doing. I'm trying to be careful to avoid a false confirmation on these things of course.

What I find most useful about this experience is that I gives me a change to question how I've gone about solving problems for the last 25+ years. Some days it sucks, because you stand there questioning something you've been doing for 10 years and wondering if you've been 'wrong' for that long. Sometimes it's awesome because you get validation of your technique.

All of us live to some degree in a bubble created by those who surround us. All of us could be fooling ourselves every day in terms of How it Should Be Done  

I highly recommend that you get out, meet some new people (or read some new blogs) and consider that what you think you know as the right thing might be improved upon.

01 November 2017


Today is the first day of National Novel Writing Month. I'm going to be one very busy camper. I hope to be able to get a few posts out each week, but coverage may be spotty. Stick with me though.