Posts

We always start from where we are

Image
Earlier on in this year, I had a really interesting discussion online with Duncan Hothersall about Scottish Independence, and Brexit. I support independence, and Duncan very much doesn't. Scotland is currently about evenly split between supporters and opponents of independence, with a small number of hardcore unionists and nationalists on either side. But many people are in the middle, and weigh up the decision based on the perceived pros and cons. In itself, this disagreement between Duncan and myself is interesting. We share a similar world-view and similar hopes for the future. We agree in many ways on the kind of future we would like to see. But we disagree on how we want to get there.  This is of course a common pattern. We often share a purpose with other people, but we disagree on the tactics or maybe even the strategy for how to achieve it, and there is a wealth of literature on how to resolve such disagreements.  But what I found fascinating was how we both responded to B

Gall’s Law

Gall’s Law isn’t really a law. It’s an observation, or a heuristic, from the early days of modern Systems Thinking. In John Gall’s 1975 book, “ Systemantics: How Systems Really Work and How They Fail” , he wrote: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” This is a great rule of thumb for helping us to create or design complex systems.  When we write software, some people think that it is better to evolve code as you go, writing code, then changing it, then changing it again.  Others think that this is wasteful, and that it is better to invest in in upfront design, or detailed estimation and planning, to avoid all this rework.  How can we decide which approach is better?  If we follow Gall’s Law, then we might have an answer. If we’re trying to create something truly co

Creating our own puzzles

In Agile tech circles, we often talk about "slowing down to speed up". For years, I've had a good gut instinct that this is true, but I’ve never untangled that paradox properly. Because slowing down makes you go slower, by definition. What is it about slowing down that paradoxically allows us to go faster? Yesterday, me and my team did an Escape Room together. We did it all together, and solved the problems collaboratively. It struck me that it would be a good learning opportunity to reflect on whether it was faster to work collectively, or if we'd have been faster if we worked individually, but in parallel. But something about the analogy with software development didn't feel right. And then it hit me. There's a missing feedback loop with Escape Rooms. The way we solve the puzzles now has absolutely no effect on the difficulty of the next puzzles, or the puzzles that we'll face next time we do an Escape Room. But in software development, the solutions we

Lessons from Yoga

 I've been doing Yoga for a few years now, and its now part of my daily routine. And as it has become part of my life, I've been reflecting on the lessons that I've learnt from the practice, and how they relate to the world of creating and changing software. Pausing In Yoga, we focus on our breathing, to calm and centre ourselves. We breathe in, we breathe out. And there's a small pause after we've inhaled, right before we exhale. And similarly, there's a larger pause in between each breath. We act, then we pause. Similarly, at the end of a Yoga session, we rest in Shavasana. We lie on our backs, and relax completely, for several minutes. This is a pause to let us relax, to loose any tension, and  to create a buffer between the Yoga and our busy daily lives. We act, and then we pause.  And when we write software, it can be tempting to skip breaks. We might work for a whole morning without stopping. Or we might finish a sprint, and go straight into the next sprin

Guest Mobbing at Emmersion

 A few weeks ago I saw a post on Twitter , asking if anyone would like to join a team as a guest-mobber at Emmersion . Unless you're a contractor, or freelance, then it's not often you get to work with complete strangers, to see how they work, what kind of problems they face, how they solve them... Anyway, Mike Clement got back to me, and once we'd sorted out the NDAs, we agreed on a two-hour session with one of their dev teams. The slot was right after work for me in Scotland, and early afternoon for them in the US.  So last night, I joined a Zoom call, and we jumped straight in to solving a production problem. They had a mob of five, with me as well, and their product owner at the start.We were looking at a problem where the user could do some input, the data should be sent off to a third-party, a response received, and then the UI updated. But something was wrong, and it didn't work. Like a lot us, they had a complex legacy system which none of them understood. It lo

Cleaning up log files for C++ Approval Tests

I wrote about the Gilded Rose kata a while back ( https://barneydellar.blogspot.com/2020/07/gilded-rose-katas.html ) and one thing I looked at was the use of Approval Testing to get the code under control.  And I went further, and investigated using the same library to test logging behaviour.  Approval Testing relies on consistent output given consistent input. But logging code typically adds the date and time to the log file. This is desired behaviour, but it makes testing against the log file hard. The C++ Approval Test library ( https://github.com/approvals/ApprovalTests.cpp ) always had support for dealing with this, but it was quite verbose. You had to create a derived TextFileComparator, override the contentsAreEquivalent() method, and then use regex to find and replace the date and time with something hard-coded. class  SpdLogComparator :  public  TextFileComparator { public:     [[nodiscard]]      bool  contentsAreEquivalent(         std::string receivedPath,         std::strin

Gilded Rose Katas

Image
Introduction Last Summer, I had the pleasure of bringing Amitai Schleier into my company for a few days, as part of his coding tour . One thing that really inspired me was his emphasis on a Learning Hour each day, and on using katas.  Katas are a short set-piece practices. The word “kata” comes from the Japanese martial arts tradition (形 - literally, "form") and is used to describe a regular repetitive, choreographed practice. Wikipedia gives a good description here  https://en.m.wikipedia.org/wiki/Kata . In software, there is a good collection of these set-pieces. Implementing FizzBuzz in a new language is a good example.  So, after Amitai’s visit, I started running katas every day. It took us a while to establish them, because we don’t have set starting or finishing times. But we now do half an hour of katas every day after lunch. We have used the time to look at TDD, TCR , Haskell, and we have used several well-known katas.  But the one we spent the lo