Unit tests are your specification

Recently a Schalk Cronjé forwarded me a tweet from Joshua Lewis about some unit tests he’d written.

. @ysb33r I’m interested in your opinion on how expressive these tests are as documentation /@DeveloperUG

— Joshua Lewis (@joshilewis) December 3, 2015

I took a quick look and thought I may as well turn my comments into a blog post. You can see the full code on github.
Comment 1 – what a lot of member variables
Why would we use member variables in a test fixture? The fixture is recreated before each test, so it’s not to communicate between the tests (thankfully).

In this case it’s because there’s a lot of code in the setup() method (see comment 2) that initialises them, so that they can be used by the actual tests.

At least it’s well laid out, with comments and everything. If you like comments – and guess what – I don’t. And they are wrapped in a #region so we don’t even have to look at them, if our IDE understands it properly.
Comment 2 – what a big setup() you have
I admit it, I don’t like setup()s – they move important information out of the test, damaging locality of reference, and forcing me to either remember what setup happened (and my memory is not good) or to keep scrolling to the top of the page. Of course I could use a fancy split screen IDE and keep the setup() method in view too, but that just seems messy.

Why is there so much in this setup()? Is it all really necessary? For every test? Looking at the method, it’s hard to tell. I guess we’ll find out.
Comment 3 – AcceptConnectionForUnconnectedUsersWithNoPendingRequestsShouldSucceed
Ok, so I’m an apostate – I prefer test names to be snake_case. I just find it so much easier […]

By |December 5th, 2015|Agile, BDD, TDD, Unit testing|9 Comments

Huge scale deployments

Deploying to 10 or 20 servers can be complicated. But what are some of the tools, tips and patterns for successfully deploying to 1,000s of servers around the world? Last month I participated in an online panel on the subject of Huge Scale Deployments, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps hosted by Electric Cloud. You can watch a recording of the panel:

The discussion progressed through a short deck of slides with big ticket titles. Plenty of interesting things were said (mostly by other people), but the main insight I had was that the practices discussed are applicable at any scale. Meanwhile, here are a few edited extracts from my musings on the video.

How do you practice huge scale deployments? How did the teams at Amazon make it work?

“I was a software developer at a little-known Amazon development center in Edinburgh, Scotland. … at Amazon, teams are responsible for provisioning environments, continuous deployment, everything on their own. Because we knew that we were picking up the pieces if it went wrong, we were going in making sure our deployment was good in early stages of the pipeline, because we had responsibility. When people have responsibility they make sure that things don’t break.”

“With regard to incentives – at Amazon there’s no need to dangle carrots, the teams know that everything that happens, designing, provisioning for expected loads, all the way to fixing problems in production, is their responsibility. So everyone practices ‘if it hurts do it more often’. It’s a natural human tendency to back off if there’s pain, but in software development, if something causes you pain you need to really work at that, you’re just not good enough at it […]

By |September 1st, 2015|Continuous Delivery, ContinuousDelivery, Musings, Practices|0 Comments

Flatulent agile

I’ve been working with a number of larger, older organisations recently and it has really brought home to me the difference between the promise of a nimble, responsive teams and the reality of a sluggish, bureaucratic behemoth. Then, looking back over years of writings, posts, promises and dreams I see frequent repetitions of the phrase “Agile says that …” What? What exactly does agile ‘say’?

I’m not going to invoke the manifesto. It’s there if anyone wants to look at it and it is a valuable historical document. Its contents are as relevant today as they were when they were written (tinkering aside), but it is declarative not imperative. It is aspirational not procedural. We can’t ‘implement’ it or ‘transition’ to it.

Instead we have the plethora of methods that existed at the time of its original drafting and a few more besides. Many of them include recipes, processes, state diagrams – but they don’t seem to reliably help organisations improve their ability to deliver. These organisations need to change, but not according to some checklist brought down from the agile mountain chiselled in stone. The agile values and principles help us suggest ways of change, but that’s as far from a recipe as the contents of a box of oatcakes are from the serving suggestion in the picture.
There are plenty of winds in the world. There are the four winds. There are the trade winds. There are the winds of change. And there is… how shall I put this delicately?… bottom wind.

One of the definitions of flatulent is “generating excessive gas in the alimentary canal”, but it’s not that relevant to what we’re discussing. A more appropriate definition for my purposes is:

“having unsupported pretensions; inflated and empty; pompous; turgid”

I’ve heard […]

By |August 27th, 2015|Agile, doa, Musings|0 Comments

Is the customer always right?

Today I’m in London for the first day of SPA 2015. I was early to the venue and I went to the registration desk to sign in.

“What’s your name?” asked the receptionist.

“Seb Rose” I replied.

“No. You’re not registered” she said.

After a few minutes of spelling out my name, and searching around on the database she did find me. She looked up at me and said: “You are Rose, Sebastian”.

It’s true she was not a native english speaker, and that I have a slight accent, but even so I think you’ve got to assume that I know my own name. The reason I bring this up is that it’s something that happens a lot in all walks of life – people assume that the system is right, its data canonical. There’s no reason to believe this – it’s a form of institutional hubris.

Start from a more humble position. Accept the possibility of ignorance, the likelihood that the problem is rooted in the system not the customer. And even when it turns out that the customer is the cause of the error remember that it’s probably a failing of the system that allowed them to screw up anyway.

The customer is often right, and when they’re not it’s not good business to rub their nose in it.

By |June 28th, 2015|Musings|0 Comments

Branching and Continuous Delivery video discussion

Following on from my previous post and discussions online, we arranged a Google Hangout to discuss things in more detail. I was joined by Dave Farley, Lars Kruse, Olve Maudal and Mike Long and you can watch the unedited video here:

I don’t think we reached any agreement and after the video ended Olve suggested that we meet again to focus on specific topics, in several sessions. Olve’s suggestions were (paraphrased by me):

pre/post-commit checks and their effect on feedback speed
benevolent dictator/trusted serf as a general model
even more about branching

If you’d like to see more, please Tweet with the hashtag #cdBranching indicating which (if any) you’d like to hear more about.

By |May 20th, 2015|Agile, Continuous Delivery, ContinuousDelivery|1 Comment

BCS: Agile Foundations

Preconceptions challenged
I really wanted to dislike this book, and in some respects I managed to achieve my goal. This is a book published to support yet another spurious agile certification (YASAC?), and I really don’t like that. The authors continuously use ‘Agile’ as a capital-A, noun, rather than the lower-case-a adjective that it clearly ought to be, and I have ranted about that before. And then they resort to anthropomorphising in the fashion “Agile doesn’t say …”, which I find hugely objectionable.

On the other hand, this book does deliver on its claim to provide “a comprehensive introduction to the core values and principles of Agile methodologies.” It describes, without too much embellishment, the fundamental and constituent principles of approaches that support a responsive development process.

The writing is clear and mostly correct, though some things are stated as facts, when they are clearly not. For example:

“There are generally three styles of Agile delivery …”
“A key concept in Agile is emergent or opportunistic design.”
“TDD validates that … the design is appropriate with minimal technical debt”

Broad horizons
This book really triumphs by continually going further and offering the reader broader avenues of discovery. There are continuous references to techniques, approaches and research that go far beyond the usual agile trivia. There’s mention of BDD, Real Options, Feature Injection, Cynefin, Maslow’s hierarchy of needs, Reinertsen’s economic model and Kotter’s 8 stage model – to name just a few.

Some of these are explained in reasonable detail, others are just mentioned in passing, but all contribute to making this book a valuable resource for someone who wants to escape the narrow confines of a typical agile transformation. There’s more to it than stand-ups and planning poker, after all.
The book is split into 4 sections:

Introducing Agile: A whistle stop tour around the manifesto, that still manages to mention […]

By |May 13th, 2015|Agile, Practices|0 Comments

Continuous delivery conversations

Last week I was at the CoDeOSL conference in Oslo. It was an interesting day, with some very good sessions, but as usual it was conversations had in the breaks that were of the most interest. I’d like to describe two discussions that I had that seem, on the face of it, to be in conflict.
Conversation #1
The night before the conference there was a meetup in a bar just around the corner from the conference hotel. I arrived a bit late and tired (because I was still recovering from the ACCU conference which had finished the previous Saturday) and struck up a conversation with Mike Long (who was also recovering from the ACCU conference). We were talking about patterns of interacting with source control that support continuous delivery – specifically the Automated Git Branching Flow that has been proposed by JOSRA.

Mike had an A5 leaflet that described the flow, including the diagram above, but I found that I needed to read the full article on the web before I could start to make sense of it. My distillation of their words is that:

continuous delivery depends on trunk always being potentially shippable
merging is always dangerous, so don’t allow complex merges onto trunk
automate the process of performing trivial, fast-forward merges onto trunk

Adopting this process (using the Open Source Jenkins plugins provided) leads to a flow that requires developers to merge from trunk before pushing their changes. As long as the automated merge to trunk that results from this push is a fast-forward merge, then everything is good. If it isn’t, then the push fails and the developer has to fix the problem locally, before attempting to push again.

Steve Smith voiced some scepticism on Twitter:

Conversation #2
At lunchtime I headed into Oslo to get an anniversary […]

By |May 2nd, 2015|Continuous Delivery, Practices|3 Comments

Making a meal of architectural alignment and the test-induced-design-damage fallacy

A few days ago Simon Brown posted a thoughtful piece called “Package by component and architecturally-aligned testing.” The first part of the post discusses the tensions between the common packaging approaches package-by-layer and package-by-feature. His conclusion, that neither is the right answer, is supported by a quote from Jason Gorman (that expresses the essence of thought over dogma):
The real skill is finding the right balance, and creating packages that make stuff easier to find but are as cohesive and loosely coupled as you can make them at the same time
Simon then introduces an approach that he calls package-by-component, where he describes a component as:
a combination of the business and data access logic related to a specific thing (e.g. domain concept, bounded context, etc)
By giving every component a public interface and package-protected implementation, any feature that needs to access data related to that component is forced to go through the public interface of the component that ‘owns’ the data. No direct access to the data access layer is allowed. This is a huge improvement over the frequent spaghetti-and-meatball approach to encapsulation of the data layer. I like this architectural approach. It makes things simpler and safer. But Simon draws another implication from it:
how we mock-out the data access code to create quick-running “unit tests”? The short answer is don’t bother, unless you really need to.
I tweeted that I couldn’t agree with this, and Simon responded:
This is a topic that polarises people and I’m still not sure why
Main course
I’m going to invoke the rule of 3 to try and lay out why I disagree with Simon.
Fast feedback
The main benefit of automated tests is that you get feedback quickly when something has gone wrong. The longer it takes to run the tests, the longer […]

By |March 19th, 2015|Agile, Practices|2 Comments

Entanglement (or there’s nothing new under the sun)

I’ve just read The Age of Entanglement : When Quantum Physics was Reborn by Louisa Gilder. It’s a tremendous book, looking at the interplay between great physicists over the whole of the 20th century. If you want to learn about quantum physics itself, this is probably not the book for you, but if a mix of science and history is your thing, then I can’t recommend this book enough. But that’s not why I’m writing this post.

As I read the book, there were two passages that jumped out at me because they were so relevant to experiences I have regularly. One was about testing and the other was about collaboration. Maybe I shouldn’t have been surprised, but there you have it – I was.

Experimental physicists understand that testing saves time. They sound a lot like developers who:
“want to slap it all together, turn it on, and see what happens.”
“you can almost guarantee it’s not going to work right.”
Doesn’t this sound familiar? Their conclusion might sound familiar too:
“People always think you don’t have the time to test everything. The truth is you don’t not have the time. It’s actually a time-saving way of doing it.”

And then I found the description of a conference that sounded like a pre-cursor to the modern, open space ‘unconferences’ that have been springing up. An explicit acknowledgement that:
“the best part of any conference is always the conversation over coffee or beer, the chance meeting in the hall, the argument over dinner.”
This led directly to their decision to:
“organise their conference to be nothing but these events. No prepared talks, no schedule, no proceedings.”
I’ve heard of regular, private get-togethers like this that go on in the software community, where a selected group of invitees hole up […]

By |February 19th, 2015|Musings, Practices, Systems, Unit testing|0 Comments

Rolling Rocks Downhill

It’s almost a year since I posted a glowing review of “The Phoenix Project” – a business novel, following in the footsteps of Goldratt’s “The Goal”, about continuous delivery. If you haven’t yet read it, then I’m going to recommend that you hold fire, and read “Rolling Rocks Downhill” by Clarke Ching instead.

I should point out that Clarke is a personal friend of mine and a fellow resident of Edinburgh, so I may be a little biased. But I don’t think that this is why I feel this way – it’s just that Clarke’s book feels more real. Both “Rolling rocks….” and “Phoenix…” have a common ancestor – “The Goal”; both apply the Theory of Constraints to an IT environment; and both lead eventually to triumph for the team and the lead protagonist.

There’s something decidedly european about Clarke’s book, which makes me feel more comfortable. The reactions of the characters were less cheesy and I really felt like people I know would behave in the manner described. (Maybe that’s because these characters really are based upon people I know ;)) There really are cultural differences between Europe and North America, and this book throws them into sharp relief. The inclusion of the familiar problems caused by repeated acquisitions and a distributed organisation only added to the feeling that this story actually described the real world, rather than an imaginary universe powered by wishful thinking. The only time that my patience wore thin was around the interventions of the “flowmaster”, Rob Lally, who is ironically a real person.

A truly useful addition in Clarke’s novel is the description of the Evaporating Cloud diagram, which (I now know) is one of the 6 thinking processes from the theory of constraints. For […]

By |February 12th, 2015|Agile, Continuous Delivery, Practices|1 Comment