Category Archives: Software development

Surprises

Posted on by

Back in the day I used to say this about test-driven development:

If ever I get a surprise, it means I have a missing test.

That is, if I’m in the GREEN or REFACTOR step of the TDD cycle and my changes make something else break, I need to add a test to document something that I must have missed previously.

I don’t think that now. These days I am much more likely to say something like:

If ever I get a surprise, it means I have accidentally discovered some connascence that I was previously unaware of. I need to eliminate it, weaken it, bring the connascent code closer together, or refactor my names so that it is clearly documented.

I’ve discovered some refactoring that needs to be done, and I wouldn’t necessarily rush to add tests.

Advertisements

Don’t forget the developers!

Posted on by

I visit numerous organisations that are implementing “agile transformations”. In many of them I see a familiar pattern:

The managers and business analysts are sent on courses and sent to conferences and given books to read; most of them change their job title to things like Scrum Master or Product Owner; they create their plans using “stories” written on post-it notes, and they organise their projects into Sprints. But only rarely does anyone help the developers change too.

These organisations have cargo cults. The developers and the testers have at least as much to learn, and need as much support as do the managers and business analysts.

In order to deliver a working product increment every two weeks, indeed to work at all effectively in an agile way, programmers need to learn a whole raft of new skills and modes of thought. Continuous delivery, emergent design, test-driven development, pair programming, mob programming, feature slicing, YAGNI, outside-in development, … The list is long; and most of the skills on it can seem at best counter-intuitive to those who have grown up working in the “old ways”.

Agile methods arose from the realisation that the creation of working software should be at the centre of everything, with all other activities subordinated (in the Theory of Constraints sense) to it. And yet I see so many organisations in which the agile transformation stops with the introduction of stand-ups, plans written on post-it notes, and maybe some 3-amigo training for the BAs.

If your agile transformation is focusing on the way execs measure ROI, or on how project plans are written, or even on how teams are managed, you may be missing out on the biggest throughput boost of all: supporting your developers in coping with this whole paradigm shift.

Of course you will get some improvements in throughput by slicing your plans into frequent releases and focusing on maximising value early etc. But it will never really get flying if your developers are still thinking in BDUF terms, integrating late, leaving the testing to be done by someone else later, hoarding knowledge, collecting technical debt, building systems in horizontal layers, relying on the debugger etc etc. Many developers only know how to work this way; many see the XP practices as counter-intuitive, if they’ve even heard of them.

So when you’re considering implementing an agile transformation in your organisation, please remember that it’s all about software development. Without the programming activities, you would have nothing to manage. Make sure to give the programmers enough support so that they can learn to work in a way that fits with and supports and enhances your agile transformation. Find someone who can teach them the XP practices and mentor them through the first 6 months of their adoption. Because if you don’t, the very thing that agile is about – programming – will hold back, nay derail, your agile transformation.

Update, 20 Oct 17

I used this blog post as the basis of a lightning talk at LeanAgile Manchester last night. My slides (without animations) are here.

An idea for retrospectives

Posted on by

I recently read 2 second Lean by Paul Akers. It’s a marvellous little book. It has re-ignited my deep-seated love for lean thinking, and in particular for continuous improvement via aggregation of marginal gains. I highly recommend you take the 2-3 hours to read it, and then look for ways to apply Akers’ ideas to your team.

Partly inspired by 2-second Lean, and partly by the mob programming practice of daily retrospectives, I’ve recently been experimenting with using daily retrospectives for continuous improvement. Imagine you ran a retrospective at the end of each day, using only the following question:

Let’s set aside the first 30 minutes of tomorrow to eliminate, forever, some of the waste we saw in our practices today. Let’s see if everyone in the team can remove at least 2 seconds of time we wasted today not delivering value. Which 2 seconds should we choose to eliminate? And what shall we do to achieve that?

What would you pick? Ideas from the teams I work with have included learning keyboard shortcuts, using Sublime Text instead of Visual Studio, deleting unused code, documenting setup steps in a wiki, and so on.

Perhaps you could also follow Paul Akers’ practice of making “before” and “after” videos of your improvement, to share with other teams? (Hopefully I’ll find the time to share some of my personal 2-second kaizen videos here soon.)

 

The Page-Jones refactoring algorithm

Posted on by

In Fundamentals of Object-Oriented Design in UML Meilir Page-Jones offers the following guidelines for system maintainability:

  1. Minimise overall connascence
    By breaking the system into encapsulated elements
  2. Minimise connascence crossing encapsulation boundaries
    By maximising the connascence within encapsulation boundaries

This feels like something of an “algorithm” for refactoring, if only we could quantify what “maximise” and “minimise” mean. In the next few months I’m going to have a stab at doing just that, with the help of audiences around Europe as I roll out my new talk “Love and Death: Everything you always wanted to know about coupling but were afraid to ask”. I plan to report back here as the wisdom of crowds helps me flesh out what the above algorithm might mean. First up is XProLo next week, followed by NWRUG in July. Watch this space…!

Agile: it’s not just about the development team

Posted on by

Last week Andy Longshaw and I ran our “Agile: It’s not just about the development team” workshop again, this time at XP2016. You can read Andy’s report, and see the posters created by the participants, here. This time we had 90 minutes, which felt a lot less rushed than the 60 minutes we had at AgileManchester last year (read Andy’s report of that run here).

Workshop in progress

Workshop in progress

We have run this workshop four times now, twice at conferences and twice as in-house training. Each time generates great discussion around how the non-software parts of the business need to change their strategies in order to support, cope with and capitalise on a highly agile development team.

Commit messages

Posted on by

Write commit messages so that:

  1. they complete the sentence “This commit will…”
  2. the commit log can be understood by your Product Owner
  3. they describe the “why” — because the “what” can be read in the diff

For example:

Make the sign-up button look like all other calls to action
Ensure the timezone is always correct on UAT
Allow clients to retrieve the time when an application is rejected

instead of:

Import the new LESS file on the home page
Updated config
Updated endpoint for rejected

An event-sourcing conundrum

Posted on by

I have a side project that I use as a sounding board to help me learn about “modern stuff”. The front end is built with React + Flux, and the back end persists information via event sourcing instead of a SQL or document database. I’m enjoying the experience of working with these tools, and so far everything has gone smoothly. But now I have a puzzle, which I will share here in the hope that one of you can point me in a good direction.

Continue reading →