Software Delivery Notebook

Podcast: Software Delivery Notebook

  • Achieving Continuous Delivery with TPF

    Achieving Continuous Delivery with TPF
    The Software Delivery Notebook
    Achieving Continuous Delivery with TPF
    Loading
    /

    This episodes look at the white paper Achieving Continuous Delivery With TPF by Bob Walker at Octopus Deploy. TPF is a set of three practices that can solve many CI/CD pipeline problems.

    • Trunk-based development
    • Progressive rollouts
    • Feature toggles

    Find out the core problems and how TPF helps, with some case studies that might hit close to home.

    TPF is much simpler, much more elegant. With trunk-based development those small frequent merges mean the main branch is basically always deployable, it’s always green.

    And then feature toggles hide any work in progress, so a new feature that’s half done doesn’t block a critical bug fix or performance improvement.

    Progressive rollouts let you get the new version deployed and fully verified in production.

  • Westrum’s study of information flow

    Westrum's study of information flow
    The Software Delivery Notebook
    Westrum’s study of information flow
    Loading
    /

    Ron Westrum is famous for his classification of organizational culture, but he’s also done great work on hidden events, and information flow. This episode looks at Westrum’s study of information flow and it contains highly relevant lessons for all organizations, not just safety-critical industries.

    When information fails to flow, it stops the “safe and proper functioning of the organization,” and looking at the flow of information is a powerful indicator of how well the organization functions.

    The properties of great information are receiver-centric. Good information…

    1. Answers the questions the receiver needs answered
    2. Is timely
    3. Is presented in a way that makes it usable by the receiver

    This paper has a whole host of insights, explored through interesting real-world stories.

  • Unpacking Weinberg’s laws of consulting

    The Principles and Practices of Consulting
    The Software Delivery Notebook
    Unpacking Weinberg’s laws of consulting
    Loading
    /

    Based on a list of laws, rules, and principles that span Gerald M. Weinberg’s two books on The Secrets of Consulting. These laws are a helpful and amusing way to get into the consultant mindset.

    They include The First Law of Consulting:

    In spite of what your client may tell you, there’s always a
    problem.

    And The Second Law of Consulting:

    No matter how it looks at first, it’s always a people problem.

    Enjoy the truth and fun of this collection of insteresting thinking angles.

  • Compliance through Continuous Delivery

    Continuous Delivery through CD
    The Software Delivery Notebook
    Compliance through Continuous Delivery
    Loading
    /

    Based on the financial industry survey by Octopus and their Compliance through Continuous Delivery report, this episode shows how recent regulations are increasing the pressure for regulated companies to improve their software delivery performance.

    You can’t meet the requirements without having a path to production that applies to all changes, whether they are routine features or security patches.

    Find out why you need to ditch the expedite process, kick out the cross-departmental approval committees, and embrace Continuous Delivery to improve your compliance.

    It becomes very clear that organizations without automated deployment pipelines really struggle. They just can’t meet the demand for increased deployment frequency that this kind of legislation requires.

    It sounds like Continuous Delivery and DevOps aren’t just nice to haves any more, they’re becoming essential for survival, especially in regulated industries.

  • Why software projects fail

    Why Big Software Projects Fail
    The Software Delivery Notebook
    Why software projects fail
    Loading
    /

    Let’s look at a classic software projects paper published in The Journal of Defense Software Engineering in March 2005. It discusses why software projects fail so often. Some of the concepts discussed are old school and the criteria for success aren’t what we’d use today, but it’s a fascinating snapshot of the problems that were faced in the old times.

    Despite its age, we still find some of these problems can surface in modern software delivery. Understanding where we came from can help guide what we do next.

    Watts S. Humphrey asks 12 questions in his paper:

    1. Are all large software projects unmanageable?
    2. Why are large software projects hard to manage?
    3. Why is autocratic management ineffective for software?
    4. Why is management visibility a problem for software?
    5. Why can’t management just ask the developers?
    6. Why do planned projects fail?
    7. Why not just insist on detailed plans?
    8. Why not tell the developers to plan their work?
    9. How can we get developers to make good plans?
    10. How can management trust developers to make plans?
    11. What are the risks of changing?
    12. What has been the experience so far?

  • Dave Farley’s CD report

    Dave Farley’s CD report
    The Software Delivery Notebook
    Dave Farley’s CD report
    Loading
    /

    Dave Farley knows a thing or two about Continuous Delivery (CD), so his State of Continuous Delivery in 2025 report based on assessments of consultancy customers is a great insight into how CD is being practiced.

    Find out what people are practicing, what they are missing, and why we need to overcome the technical skills cliff that still remains.

    [The top 10%] are strong across the board. They’re really setting the standard. For instance, over 95% of them are doing trunk-based development… and they have truly comprehensive test automation; unit, integration, end-to-end, the works. Plus they have complete deployment pipeline automation… and comprehensive observability and monitoring.

  • Multi-tasking: Executive control in task switching

    Executive Control in Task Switching
    The Software Delivery Notebook
    Multi-tasking: Executive control in task switching
    Loading
    /

    A big myth of business is that multi-taskers are the go-getters who deliver the most work. The research, though, shows that these multi-taskers deliver work slowly and have problems with quality and accuracy. In fact, the more someone rates their multi-tasking skills, the worse they perform.

    Find out how researchers tested these ideas to discover the true impact of multi-tasking and the trouble with context switching, which has a cost influenced by task difficulty and rule complexity.

    Even when people were switching between simple addition and subtraction, with cues helping them prepare, there was still a measurable cost.

  • AI coding assistants and perceptions of productivity

    AI coding assistants and perceptions of productivity
    The Software Delivery Notebook
    AI coding assistants and perceptions of productivity
    Loading
    /

    A very deep exploration, conducted by METR with 16 open-source developers and 246 real issues, has looked at perceptions and reality of productivity when using AI coding assistants. Titled Measuring the impact of early-2025 AI on experienced open-source developer productivity, the report tackles something we’ve known for a while, our perception of productivity is no indicator for reality.

    We had the same issue with multi-tasking, where people thought they were more productive, but the reality was they were less productive. So, how does this translate to software delivery with AI assistance? The TL;DR is a perception of a 20% less time to complete tasks, but a reality of an additional 19%. Less than half of AI suggestions were accepted by the developers.

    A lot of earlier studies looked at artificial problems, things that were self contained, maybe didn’t reflect the messiness or real code, or they relied on metrics that, honestly, AI could game.

  • Unraveling Software Cycle Time: Messy, Not Magic

    Cycle Time: Messy not Magic
    The Software Delivery Notebook
    Unraveling Software Cycle Time: Messy, Not Magic
    Loading
    /

    This episode looks at the preprint, No Silver Bullets: Why Understanding Software Cycle Time is Messy, Not Magic, from John Flournoy, Carol Lee, Maggie Wu, and Catherine Hicks from Pluralsight.

    The paper looks at how cycle time is influenced by a large number of factors, with none being a silver bullet. The compound affect of many small improvements is the way to improve cycle times. There’s also a deep look at unexplained variation and noise that makes this a hard area to study.

    There are countless tiny factors that can influence how long a single task takes… and what’s particularly striking, or maybe a bit humbling, is that this variability across individuals is even greater than the variability across organizations.

  • Work Is Water: Flow, Not Drowning

    Work Is Water: Flow, Not Drowning
    The Software Delivery Notebook
    Work Is Water: Flow, Not Drowning
    Loading
    /

    From the article Work Is Water on The New Stack.

    Modern work environments often overwhelm individuals with an endless stream of tasks, akin to a river flooding its banks. It suggests that attempting to rush work through only exacerbates the problem, leading to more interruptions and a feeling of being constantly submerged.

    Embrace a “flow” mentality inspired by natural waterways and find out how slowing down, continuous small-scale planning, and intentional decision-making is how you get things done.