Agile

/Agile

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 https://t.co/YpB1A3snUV /@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

Flatulent agile

Recipes
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.
Wind
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

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.
Structure
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

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

Starter
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

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

Always Be Coding

Last night I finally got around to watching Erik Meijer’s keynote from last year’s Reaktor conference. It was called “One Hacker Way” and, while it contains much that is apocryphal – or at least wildly inaccurate – it scores over the older, more pedestrian type of keynote in two important ways: first it is highly contentious, and second, Erik sports a bright, tie-dyed T-shirt.

Some of the highlights of this personal rant were:

“Agile is a cancer”
“TDD is for pussies”
Stand-ups eat into valuable coding time
Coders should be treated (and paid) like professional athletes
Hierarchical structures work for the army and the church, so they must be good

There were times that I found myself nodding in agreement, though – when he compared Scrum certification to a pyramid selling scheme, for instance – but mostly it was just opinion, conspicuously lacking the support of empirical data (which was one of his criticisms of agile).

I could go on, but if you’re still interested then I recommend you just go watch the video.

My final thought is that whole experience was vaguely reminiscent of a scene from the excellent movie “Glengarry Glen Ross”, where Alec Baldwin’s character harangues the dejected real-estate salesmen:
F*** YOU, that’s my name!! You know why, mister? ‘Cause you drove a Hyundai to get here tonight, I drove an $80,000 BMW. That’s my name!! And your name is “you’re wanting”. And you can’t play in a hacker’s game. You can’t write code. Then go home home and tell your wife your troubles. Because only one thing counts in this life! Checking in code! You hear me, you f***in’ faggots? A-B-C. A-Always, B-Be, C-Coding. Always be coding! Always be coding!
And, if you’re over 32 (when Erik […]

By |January 16th, 2015|Agile, doa, Musings, Practices, TDD, Unit testing|0 Comments

Reduce, Reuse, Recycle

From http://kids.niehs.nih.gov/explore/reduce/:
Three great ways YOU can eliminate waste and protect your environment!

Waste, and how we choose to handle it, affects our world’s environment—that’s YOUR environment. The environment is everything around you including the air, water, land, plants, and man-made things. And since by now you probably know that you need a healthy environment for your own health and happiness, you can understand why effective waste management is so important to YOU and everyone else. The waste we create has to be carefully controlled to be sure that it does not harm your environment and your health.
What exactly is “waste?”
Here’s a list (not exhaustive, by any means):

Code that doesn’t get used
Log entries that give no information
Comments that echo the code
Tests that you don’t understand
Continuous integration builds that aren’t consistently green
Estimates that you aren’t confident in

How can you help?
You can help by learning about and practicing the three R’s of waste management: Reduce, reuse, and recycle!

Reduce – do less. Don’t do something because that’s what you’ve always done. Do it because it adds value; because it helps you or a colleague or a customer; because it’s worth it.
Reuse – repetition kills. Maybe not today or tomorrow, but eventually. Death by a thousand cuts. Eliminate pointless repetition,  and go DRY (Don’t Repeat Yourself) for January. You’ll enjoy it so much, you’ll never go back.
Recycle – is there nothing to salvage? Really? When you find yourself building that same widget from scratch again, ask yourself “why didn’t I recycle the last version?” Was it too many implicit dependencies? Or was the granularity of your components not fine enough? Try building cohesive, decoupled components. Practice doing it – it gets easier.

By |January 12th, 2015|Agile, Cyber-Dojo, Musings, Practices|0 Comments

Do you practice BDSA?

I get to visit a lot of teams. I talk to my peers about their experiences too. For every agile success story there seem to be a load of less happy outcomes.

There are three common ways that I’ve seen agile ‘adoption’ go wrong, and they are:

Bondage – “You can never change the business. That’s just the way things work here.”
Domination – “That estimate is too big – make it smaller. These tasks are assigned to you.”
Sadism – “Work longer hours. Honour your commitments. Of course you will work on multiple projects”

If these sound familiar, then maybe your organisation uses BDSA – Bondage, domination and sado-agile.

By |December 18th, 2014|Agile, Musings, Practices|0 Comments

Half a glass

Is this glass half empty or half full?

There’s normally more than one way to interpret a situation, but we often forget that the situation itself may be under our control.

I often find my clients have backed themselves into a corner by accepting an overly restrictive understanding of what they’re trying to achieve. They will tell me, for example, that this story is too big BUT that it can’t be split, because then it wouldn’t deliver value. Or, they might be saying that there’s no point writing unit tests BECAUSE the architecture doesn’t support it. Or even, it’s not worth fixing this flickering test, because it ALWAYS works when they run it locally.

I encourage them to rethink the situation. A slice through that story may not deliver the final solution the customer needs, but it will act as a small increment towards the solution. Minor refactorings are usually enough to make a section of the code independently testable. That flickering test is undermining any confidence there might be in the test suite – fix it or delete it.

Don’t try to put a spin on a half-full glass – rethink the glass.

Instead of asking if the glass is half-full or half-empty, use half a glass.

(It turns out that wittier minds than mine have already applied themselves to this proverb – here’s a bumper collection.)

By |December 15th, 2014|Agile, Musings, Practices|0 Comments