Clean Code: what is it?

Recently I helped facilitate some discussion workshops on the topic of Clean Code. Each of the discussions seemed to be predicated on a belief that readability is the most important criterion by which to assess whether code is Clean. Indeed, the groups spent a lot of time discussing ways to establish and police coding standards and suchlike. While I agree that this can be useful, I felt the discussions missed the aspects of Clean Code that I consider to be the most important.

So I thought it might be useful here to attempt to describe what I mean by the term…

Continue reading

Consumer-driven development

In common with many other programmers I have been using the term “outside-in” development for a long time. I suspect I first encountered it in the writings of Steve Freeman and Nat Pryce, and I’m sure they got it from someone else. Unfortunately the term can be confusing (I find its Wikipedia page baffling), and I find that it doesn’t capture the whole essence of the way I write software these days. I have also tried using the term “programming by intention”, as advocated by Ron Jeffries. But that term seems to have a life of its own which is only tangentially related to the way Ron uses it.

The approach I want to describe is this: I begin with the code that wants to consume the outputs of whatever I’m about to develop. And then I work backwards. First I hard-code those outputs by creating new code “close to” the consumer, so that I can see that they work. Then I push the hard-coded values further down one layer at a time, until I’m done. (I am also likely to write automated tests, but only at the highest convenient levels rather than having tests for every new level of decomposition I discover. And that’s a story for another day.)

So the core of the approach I use is that I begin with a consumer and I write some code to make them happy. Then I treat that new code as the consumer for a new layer of code, and so on. Each layer is written “intentionally”, and does just enough to satisfy the layer above it (and thus all of the layers above that).

And where some layer is providing hard-coded values to its consumer, I think of that code as making simplifying assumptions. It does the job it was asked to do, but only serves a tiny fraction of its audience’s ultimate needs. These hard-coded values aren’t fakes or prototypes, they are a way of creating thin vertical slices quickly. And once I know they are correct, my next coding episode will be to bust one or more of the assumptions by driving the code down to the next layer of detail.

I want to call this Consumer-Driven Development. It’s nothing new, but it seems to surprise teams whenever I demonstrate it.

(I have some availability in the next few months if you would like to see this in action and learn how to apply it to your code.)

Surprises

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.

Don’t forget the developers!

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

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

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

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.