Hiccupps

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