Hiccupps

If you've met me anywhere outside of a wedding or funeral, a snowy day, or a muddy field in the last 20 years you'll have seen me in Adidas Superstar trainers. But why? This post is for April Cools' Club .  --00-- I'm the butt of many jokes in our house, but not having a good memory features prominently amongst them. See also being bald ("do you need a hat, Dad?"), wearing jeans that have elastane in them (they're very comfy but "oh look, he's got the jeggings on again!"), and finding joy in contorted puns ("no-one's laughing except you, you know that, right?") Which is why it's interesting that I have a very strong, if admittedly not complete, memory of the first time I heard Run DMC. Raising Hell , their third album, was released in the UK in May 1986 and I bought it pretty much immediately after hearing it on the evening show on Radio 1, probably presented by Janice Long, ...

  I told you how much I love Kill it with Fire by Marianne Bellotti in This is Fire and you can see it in my copy above too. It's a book about dealing with legacy systems but in the first couple of chapters grounds its thesis in the marketplace, thinking about how products, the constraints on them, and the context in which they sit change in controllable and (more often) uncontrollable ways. This might not seem very "tech" but in fact is fundamental to understanding how we seem to bounce back and forth between the same kinds of solutions, why some of them become legacy, and why we should think carefully about radically changing a working system. To be clear, this information is not necessary to get the core benefits of the book but I found it fascinating and wanted to try to triangluate concepts such as Alignable and non-alignable differences Service-dominant Logic Hype Cycle Unique Selling Proposition Cro...

  Kill it with Fire is ostensibly a book about legacy systems but is packed with good advice about managing any significant project. In one chapter Marianne Bellotti talks about gathering consensus, showing progress, and maintaining momentum. It's probably coincidental but she happened to use several words that start with "pr" when describing some of the key aspects of her approach. I liked the description a lot, but I also liked the pun, so I recast the broad ideas with a Public Relations head on: Provoke a need. You'll have observed that people tend to care more about urgent than important. What urgent hook can you hang your important project on? Is there a security issue, a performance issue, a cross-team ambiguity, or anything else that can be used to motivate others?  Promote the value of the project to whoever matters and will listen. Be prepared to cast the value in their terms rather than yours. The head of marketing doesn't give a crap about your tech de...

    Kill it with Fire is by Marianne Bellotti is a truly awesome book about dealing with legacy systems. If you're in software you need to read it and this high-level summary is my attempt to persuade you to do that, right now. What is legacy software? an existing system, onboarding is probably hard because of its age, design patterns are probably consistent but out of date, it will probably still scale if the infra scales.  (Note that tech debt generally isn't legacy by this definition, although that doesn't matter. Much of the book is relevant to both.) How do we end up with legacy software? Choices made over time, decisions that seemed pragmatic, unexpected or undesirable constraints, re-orgs, accidents, compromises, ...  Why do we seem so keen to throw legacy software away? Because writing is easier than rewriting, because we bias to see only the positive possible outcomes, because we can try our ...

In a recent episode of the Vernon Richard show , testing's dynamic duo were inspired by Valentine's Day to talk about their love for our craft. On the topic of tools, Richard sings the praises of Selenium, but Vernon takes a different tack, instead talking about tool creation ... and me!  I worked at the same company as Vern for a couple of years and we'd find time to pair on something most weeks even though our responsibilities didn't overlap at all. Sometimes he'd bring a problem, sometimes it'd be show-and-tell about what we were working on, occasionally it was about people and process, but what really lit him up was when we looked at code together, particularly if we built something. I was out walking and listening to podcasts when the episode popped up in my feed. Honestly, it was a strange feeling to hear myself being talked about, even though Vern gave me a heads-up that he'd done it just after it was recorded. What he said is nothing that he hasn...

Whatever our workplace constraints, we have agency over our own actions and the choices we make impact us, those around us, and the work we do together. We'd prefer to make good choices, naturally, but good for who, when, why? In a short talk that I gave to one of my teams this week, I pulled out nine heuristics for working that have served me well over the years. Heuristics are rules of thumb: things that generally give the right kinds of result but are fallible, a good default but not a guarantee.   The talk covered three core areas: being clear to yourself and others navigating relationships doing the work effectively and here's the slides: You'll notice that there are no credits in the slides themselves. Instead I linked to blog posts where I've pointed to the sources and commented on the interpretation I've taken, or the use I've made, or the value I've extracted. That's important, because these ar...

  Recently a few people have asked me how I test AI. I'm happy to share my experiences, but I frame the question more broadly, perhaps something like this: what kinds of things do I consider when testing systems with artificial intelligence components .  I freestyled liberally the first time I answered but when the question came up again I thought I'd write a few bullets to help me remember key things. This post is the latest iteration of that list. Caveats: I'm not an expert; what you see below is a reminder of things to pick up on during conversations so it's quite minimal; it's also messy; it's absolutely not a guide or a set of best practices; each point should be applied in context; the categories are very rough; it's certainly not complete.  Also note that I work with teams who really know what they're doing on the domain, tech, and medical safety fronts and some of the things listed here are things they'd typically do some or all of. Testing ...

  My daughter's high school requires its students to have access to a laptop at home for school work. The school's trust is a Microsoft shop so her computer needs MS Teams to be installed locally and she has access to the online Office 365 suite through a school account. No problem, right? Yeah, right, until it was. Last year sometime she complained to me that she couldn't log in. When she tried she was confronted with a dialog box "Your Organization requires you to change your pin" that wouldn't let her proceed with setting a " Hello PIN ".  I have an account on her machine (because of course ) and I found that I was getting the same problem and the same message. But which organisation is this? I don't want to sound too full of myself but I am the Lord of IT in our household organisation and I certainly didn't ask for this. Naturally, I did some research online and on her machine ... after reluctantly setting th...

In What We Know We Don't Know , Hillel Wayne crisply summarises a handful of research findings about software development, describes how the research is carried out and reviewed and how he explores it, and contrasts those evidence-based results with the pronouncements of charismatic thought leaders. He also notes how and why this kind of research is hard in the software world. I won't pull much from the talk because I want to encourage you to watch it. Go on, it's reasonably short, it's comprehensible for me at 1.25x, and you can skip the section on Domain-Driven Design (the talk was at DDD Europe) if that's not your bag. Let me just give the same example that he opens with: research shows that most code reviews focus more on the first file presented to reviewers rather than the most important file in the eye of the developer. What we should learn: flag the starting and other critical files to receive more productive reviews. You never even thought about that possi...