On Friday 11th September, I was at Code Craft Conf (@codecraftuk) in Glasgow facilitating a Guided Conversation on Test Driven Development. It was a great event and I hope it becomes a regular fixture in the calendar. Many thanks to the organisers.

Here are the 12 questions I planned. We didn’t get through them all, but we did have many entertaining discussions over the session:

* Why do we test/why do we test first ?
* Where does TDD add “value” ?
* How does test “value” vary over time ? (life-cycle from writing test first to it becoming part of the regression pack)
* When is TDD not appropriate ?
* What’s are the qualities of a good test ?
* Do you have to be strict about test types? Unit vs. Collaboration vs. Integration etc.
* What is the hardest things about TDD ?
* How do you determine the right ratio of test types ?
* Do you care about code coverage ?
* What stops you/others from practicing TDD ?
* Does TDD have an effect on team dynamics ?
* Can you prove that TDD delivers software more effectively than other methods ? (soliciting real stories & comparing “war stories”)

I’d be interested in your thoughts on any of them…might even motivate me to blog more ūüėČ

Lean Agile Scotland 2013

August 11, 2013


I’m speaking at the Lean Agile Scotland conference on the 19th/20th of September ūüôā The subject is SOLID TDD and the abstract is below.

SOLID TDD

Software developers generally don’t write poor, unmaintainable code out of any malicious or deliberate intent. They do it because software development is complex and there is not enough feedback in the process to ensure they adhere to good SOLID OO principles. By using TDD, and listening to the feedback from the tests, you can be guided to adhere to the SOLID principles…resulting in improved TCO and significant quality improvements.

Lean Agile Scotland

It’s a really good conference with a wide variety of speakers. I enjoyed attending so much last that I proposed a talk this year and wrote a two part review of the sessions I attended in 2012 (part 1, part 2). It’s being held at Our Dynamic Earth in Edinburgh and you can check out the list of speakers here. I’ll hopefully see you there…and if you post a comment I’ll see if I can get you a discount code ūüėČ


A few years ago I was lucky enough to attend Tom & Mary Poppendieck’s Lean Software Engineering course when they visited Glasgow. One of my colleagues recently reminded me of the assertion Mary made on that course that Test Driven Development is a minimum bar for a professional software developer to reach. With that in mind, I came up with the message below that I hope will inspire & motivate or at least catch the attention of people just starting out in this line of work (and perhaps some of those who’ve been around a while too).

What is a professional software engineer?

Wikipedia defines a professional as:

I don‚Äôt like that definition, it’s far too narrow. It defines a professional in terms of group membership and ability to generate income. If I want to have someone on my team, hire someone, those are not the top attributes I am looking for. When I build a team, I want to want people who care about quality and focus on maintaining high standards consistently…not just when it’s easy to do so.

Perhaps we should stop using the word ‚Äúprofessional‚ÄĚ to describe quality-focused software engineers and go for something more like ‚Äúsoftware artisans‚ÄĚ or “craftsmanship” to indicate the qualitative attributes we seek?

What is the difference between a professional and an amateur?

I think we confuse professionals and amateurs (gifted or otherwise). I can use a hammer and saw, I could probably build a fairly basic shelter given enough time…I wouldn‚Äôt want to live in it because it would be a death trap, but it would probably be ok in the very short term to keep safe from the elements. If I wanted to build a permanent home, I‚Äôd get professional builders & architects in to do the job properly.

So how can we separate amateurs from professionals?

I think it can be summed up by the aspirations of the individual:

  • An amateur aspires to achieve perfection
  • A professional aspires to deliver very high quality results, consistently

An example

I know several very keen amateur photographers. They have all the latest cameras and lenses, they know all about shutter speeds, focus, exposures, lighting, etc. Most of them have taken some absolutely spectacular pictures. However, those pictures generally represent a huge investment in time, and more discarded pictures than they’ll ever admit to. Professional photographers generally can get a very high quality picture in a fraction of the time and their pictures are generally of a far more consistent quality. This is because they have mechanisms and practices in place to govern the quality of their output. Sure, there might not be as much free expression in their work as in an amateur, but that is most likely the nature of the pictures they are being asked to capture, rather than taking pictures of whatever you like, whenever you feel like it. I think that the same is true in software development.

Low Barrier of Entry

The barrier of entry to software development is very low. This means there is a broad spectrum of quality across the industry. I recall being about 7 years old and getting the computers in Tandy to display my name, infinitely scrolling across the screen. I can write a program, does that make me a professional software engineer?

When I was a student, I wrote some MS Access and VBA front-end to manage stock and re-ordering from suppliers. I earned money from that, which I lived off of. Does that make me a professional software engineer?

A long time ago I passed my Java Programmer Certification, my degree also qualified me for some kind of partial membership to the British Computing Society (can you tell that I’m not overexcited by that?). I’m a member of two professional groups, does that make me a professional software engineer?

We need a culture of quality, we need to be software artisans.

Becoming a software artisan is not about ticking a few boxes, reading a book, getting your code to compile, then declaring it to the world how wonderful you are. It’s a journey that starts with a sometimes difficult realisation:

  • You are not the world’s most clever software developer
  • You are probably not even in the top few percentile

That’s OK, you are in the majority. That doesn’t mean you can’t be a good software developer, it just means that you need to work at it and adjust your attitude for learning. Understand that you are not perfect, and introduce good practices and checks to ensure that you are producing a quality product…rather than just banging away on the keyboard until it “seems to work”.

Test Driven Development is exactly the sort of process that can raise the quality of your code dramatically, at the same time as reducing the chance that it won’t work. People make mistakes, quite often silly mistakes, sometimes more complex and subtle ones. If you’ve crafted your test before you start coding, then you’ve got a clear, black & white (green & red?) indication of whether you have made a mistake or not. It provides you with confidence to try out different design patterns and refactoring. TDD is a software developers safety net.

Following the SOLID ideas around writing good OO code, that’s something else that can raise the quality of your work. It will make it more robust, easier to use, more readable/less confusing, more amenable to refactoring, and various other positive things. However, you have to remember to follow those ideas with all the code you write. TDD guides you in the direction of the SOLID ideas because the further away from them the code is, the harder it is to test. A difficult test is an indication, a code smell, that the code under test might be able to be refactored/redesigned to be more easily testable…and that very often involves making it more SOLID.

TDD, it’s not just a good practice, but it enforces other good practices too!

Learning TDD

I’ll not sugar coat this, TDD is hard to learn without lots of practice. However, the same can be said of any worthwhile skill. I like to think of it like riding a bike. We can all agree that travel by bike is faster than walking…but not the first time you ride a bike. No, you get grazed knees and bruised elbows as you fall off, but gradually you stay on for longer and longer and it eventually becomes second nature and you start to achieve your potential.

There is a great ring of truth to the rule on 10,000 hours of practice leading to mastery of a subject rather than some innate talent. There are some practices you can do to cut down on that time that I’ll steal from a rather good infographic.

  1. Get a coach
  2. Surround yourself with like-minded individuals
  3. Build expert habits
  4. Don’t waste time on the small stuff
  5. Deliberately practice (not just mindless repetition)
  6. Teach others
  7. Find someone to kick your butt if you fall off track

I reckon I’ve clocked up at least my 10,000 hours of TDD, and I’m STILL learning new and better ways to do it.

The Essence of Agile

January 21, 2013


I love to talk about Agile software development, Lean principles, and am currently trying to get a better grip on Rightshifting. However, when people ask me for advice it can be hard to recall details and specifics, especially if it’s either an area you haven’t thought about for a while, or something that you maybe only have limited perspectives or experience of. When this happens, it’s invaluable to be able to reach for some guiding principles.

The Agile Manifesto is a wonderful resource for this and I hear it’s even being refined (continuous improvement is a wonderful thing). Generally, when asked about them, I’ll end up mis-quoting them…even though I understand what they are about, why they were written down, how they are generally interpreted, etc. Who would have though that those 4 statements would be so difficult to remember? So I wanted to capture an even simpler interpretation of them. I was also keen to include as much from Lean as possible too. It struck me that the strongest, most often recurring theme is “feedback”…and the more I look at it, the more I’m convinced that Feedback is the very essence of Agile. I should probably back that up with evidence of some kind, or at the very least, my opinions and observations.

Feedback

If we examine the Agile Manifesto, we can see that it is all about favoring rich, prompt feedback over other options.

  • Individuals and interactions over processes and tools

This is all about interacting with people, and in general, people are pretty good at giving prompt, quality feedback. Sure, we could all be a little better at it, but you generally get much more feedback talking to someone than using a tool or following a process to accomplish the same goal. For example, handing over a piece of work in a team distributed by time-zone. You could follow the process and update the story with the latest information, and you could use a tool, JIRA perhaps, to capture that information and make it available remotely to the rest of the team. However, having a conversation and brief guided tour of the feature in it’s current state imparts information much more effectively, and provides opportunity for questions and clarification.

  • Working software over comprehensive documentation

The documentation for a project is rarely a good guide to whether the software works or not…even when it gets completed. The problem is that documentation generally lags behind the software product and is often quite far down the priority list when identifying new work. Ultimately it provides poor quality feedback, due to it generally being out of date, and it doesn’t provide it in a useful time frame.

On the other hand, working software is a very rich feedback environment with every click and gesture providing more feedback instantaneously. Continuous integration, yet another feedback mechanism, should allow you to get access to such rich feedback each day (or even more frequently).

  • Customer collaboration over contract negotiation

Our customers write stories in the form of “As a…, I want to…, So that…”, and that’s a good thing. However, it’s just a starting point for a much more detailed conversation about the details. It provides opportunity for change too. Instead of asking for every feature they can think of up-front, they are involved in the evolving product, which should allow them to select and prioritise work in an intelligent manor.

Contract negotiation is a much slower process and much more guarded in the language used. I always see it as both sides trying to make sure they are not going to be punished for failure rather than a collaborative process to deliver something. So it’s not particularly prompt, and the language used tends to disguise the true meaning…so not very high quality either.

  • Responding to change over following a plan

Prompt feedback in essential as the longer you go without feedback, the more opportunity you have to go down the wrong path…or inversely, the more often you get feedback the more opportunity you have to perform a course correction based on the latest information at hand.

Following a plan when you know it to be inaccurate or incorrect (or even a complete fantasy) leads to a culture of no longer questioning, just doing.The act of planning is invaluable, it forces you to consider options and think about how things will work out. However, the plan itself diminishes in value rather quickly as the assumptions and estimates it was built around meet up with reality. Sometimes it’s value drops to zero (or in fact below zero and becomes a burden) even before you start following it.

Test Driven Development

High quality, prompt feedback turns out to be the key concept to all sorts of other Agile software development practices. My favorite example would of course be Test Driven Development (TDD). This provides feedback on a number of levels:

  • Seeing the test results go from failing (red bar of shame) to passing (green bar of joy) is the most obvious form of feedback provided by TDD and should start a round of refactoring now you are in a “good” state.
  • By writing the test first, you get feedback on your understanding of the task. It is very difficult to devise a test when you are unclear on the desired behavior.
  • By writing the test first, you get feedback on the state of the existing code-base. If the test is difficult to write, that feedback is telling you that you should first look at refactoring/redesigning the surrounding code.
  • By running all the tests frequently, you are getting feedback on the state of the entire project and how your current piece of work is integrating with it.

The huge advantage of TDD is that you get this feedback really quickly, it’s incredibly¬†targeted¬† and it’s very specific. That is an almost perfect definition high quality, prompt feedback.

Pair Programming

I’ve heard code reviews talked about as a poor man’s substitute for pair programming. While I agree with the sentiment and acknowledge that both provide feedback on code, I think the gap between them in practice is much, much bigger than most people realise.

The obvious difference is that code reviews happen after the code has been written…sometimes quite a long time after the code has been written. So code reviews do not provide prompt feedback. This is bad…actually, I’m not sure that “bad” the right word. Maybe I should use “disappointing“? Yes, this is disappointing because the effort is being spent to review the code but the¬†opportunity¬†for getting appropriate returns on that investment have passed by already. In my experience, code reviews generally provide a lower quality of feedback than pair programming too. This is partly because they are conducted some time after the code was written, but also because it’s much harder to really understand a piece of code when you were not there at it’s creation.

So there you go, it’s all about the feedback. Make it high-quality, and seek/provide it promptly. I’ll grant you, it’s not exactly an epiphany, but it was an observation I thought I should share. Feel free to share or suggest your own observations on feedback in the comments section…or even to disagree with me.


My friend and colleague Wayne Grant¬†posted an excellent blog/summary of his experiences at Lean Agile Scotland 2012. I was there too and this spurred me on to finish writing about what I got out of the conference too. I’m trying to describe the thoughts I had about some of the talks rather than summarising the content (if you want a summary of the content, check out the Schedule on the link to the conference above), so please let me know if you think I’ve completely missed the point on any of them.

TDD

Common Objections to TDD
As I’m running TDD workshops myself, I felt that I had to attend the two TDD talks just in case I was missing out on any new thinking on the subject. First up was Seb Rose (@sebrose) with¬†Common Objections to TDD (and their¬†refutations). Seb had run a survey on the web gathering objections to TDD and this was an entertaining walk through them followed by discussion of why it was or wasn’t a valid one.

I found it very interesting in Seb’s results, that of the teams claiming to “be agile”, only about half were¬†using¬†TDD. I consider TDD to be core practice and apply the principle to many things outside of software development too as it brings me focus, forces me to ensure I have a good understanding of the task at hand, and provides a measurement of success afterwards. For example, if I’m about to make a phone call I often think of a test-case to describe the call:

  • My car will be booked into the garage…or my team will get to work on a new project

This sets me up for the call and during the call I can refer to it to make sure that it’s moving in the right direction or if I’ve become distracted/side-tracked, I can steer it back around. When the call is over I have a very simple check to see if it was a successful call or not. Maybe I take these things too far, but it works for me as I’m easily distracted.

TDD Pitfalls

The second talk on TDD was Brian Swan (@bgswan) with TDD Pitfalls. I’ve know Brian for some time and didn’t think there would be too much contentious material in his talk but I was motivated to question “Tests as Documentation” as a pitfall.

I don’t like comments in code for a number of reasons, but the biggest one is that they are always out of date. Well, that’s not true…but it very quickly becomes the case in a changing code-base and there is no easy way to tell, so I assume they are…and more often than not, delete them. For me, when I want to understand what a class does and how it should behave, I always read the tests first and find good value in that when they are written well.

I think what Brian was getting at in his talk was that it is very hard to write tests that clearly ¬†describe the¬†behaviour¬†of the class…and forcing yourself to do that is the pitfall, and I’m thinking that he might have a point. It’s very easy to expend a lot of effort trying to achieve this and when you look at the code you still, eventually (I’ll still read the tests first) end up reading the implementation.

BDD

BDD: Busting the Myths

Related to TDD, there was BDD: Busting The Myths with¬†Gojko Adzic (@gojkoadzic)…and if there’s an award for most entertaining talk of the conference, Gojko wins it easily. My exposure to BDD has always been at arms length and been dominated by people showing off how clever the tools are. I’ve never been convinced of it’s value because of this exposure, but have always felt that I was writing off something that could be¬†immensely¬†valuable.

What I took away from this talk was that, as I’d suspected, the tool was just a distraction. BDD is all about facilitating the conversation between the customer and the¬†implementer. That there are some tools to capture this is merely a convenience and I don’t think we’ll ever get to the state where the customer can just turn up with a set of BDD tests (am I even allowed to call them tests?) to hand to a development team.

The conversation is where all the knowledge about the work/story/feature comes from and BDD tests are used to steer that in much a similar way as TDD focuses code and makes you ask the questions around behaviours.

The big revelation I had was that these BDD tests have a much shorter shelf-life than I had imagined. While talking about the costs of maintaining large BDD suites, Gojko was discouraging their use for regression testing of applications (well, certainly using them verbatim as the regression test). I had always struggled to imagine the customer truly owning the tests and maintaining and updating hundreds of them over the life of the product. By suggesting that the most value for them is in the initial implementation and perhaps not maintaining them further down the line seemed to make them much clearer and usable/well defined in my head.

End of Part 1

So that was Part 1, I hope it wasn’t too rambling and that perhaps you even found it interesting. In Part 2 I’ll be talking about People, Kanban, and Rightshifting and some new things I’d like my team to try out.


I really enjoyed Martin Fowler’s recent article on Test Coverage, and in particular I liked the graphic he included in it:
Image has gone :-(

This simple diagram sets out very clearly what test coverage is good at measuring and what it is not. I think that is a very important distinction to make because coverage is no indication of quality, just of what is and isn’t tested.

This appears to be at odds with a current wave of thinking (well, one that I’ve observed anyway) where a message comes down from senior managers that all projects must have at least xx% of test coverage. The repercussions of not achieving this target vary from audit actions to remedy the coverage all the way through to not allowing projects to be released until they hit the magic number…and the number varies wildly as well…but the thinking behind this is common, and flawed: High Test Coverage == High Quality Code.

Correlation != Causation

Correlation does not imply causation, but once that link has been pointed out it can be difficult to ignore without a solid understanding of what you are observing and why there is a correlation.

The correlation is there, plenty of projects with high test coverage are of excellent quality. These projects tend to be ones driven by the sensible implementation of good tests as and when required, quite likely following some kind of deliberate practice like Test Driven Development…but not necessarily. The thing to note here is not the quantity or coverage of the tests, it’s the use of good tests, when and where required.

The other side of this is where a target is set and the team has not been writing tests all along. They quite often panic when presented with a target and immediately look for shortcuts. The reason for this could be that testing is an often overlooked skill and, from my experience, a large number of developers mistakenly think that it’s beneath them. Not always the case, but this is a blog post so I feel justified in my over-generalisation.

I’m not saying that it’s easy to retro-fit good tests to a relatively untested code base. Far from it as without considering the testing up-front, it’s likely that the code is not organised/designed in such a way as to make testing easy. I’ve seen many teams jump on a product that promises to write all the tests they need, automatically, with minimal input. The problem with these tests is that they are rarely the high value tests that are needed, and they are applied mechanically across the project with no sense of context. More importantly, they remove the knowledge and understanding that a developer would gain by thinking through what tests are relevant and how the code should behave.

So, what should we do?

First of all, we should stop selling code coverage as a measure of quality. It’s not. However, it can be useful in spotting projects where the test coverage is particularly low or to spot trends in evolving code bases.

When coupled with other tools to identify complexity and rate of change (of the source code over time) then you can identify good areas to examine and see if you could write more tests. I imagine that there are even more interesting and useful insights to be had by combining other measures, feel free to comment on this if you have any good ones.

Aiming for 100% code coverage is a noble goal, but it should only be an aspiration and definitely not a target…and you still shouldn’t confuse it with a stamp of quality assurance.

Personally, I struggle to do anything other than TDD these days but I understand it’s not the path of least resistance and can be difficult to learn. Having said that, if you are not writing tests for your software then you are either incredibly over-confident, incredibly naive, or both.

End with an analogy

A Road network

Like any analogy, I expect this one will have many flaws but I’m going to use it anyway.

  • Would you consider that the road network would be improved just by adding more roads until we reached saturation?
  • Regardless of the quality of the roads?
  • Even when they were built where nobody lived, traveled, or wanted to go?