1. 13
  1.  

  2. 6

    (tl;dr of the below: even if the article’s subject doesn’t interest you, the author’s use of a surprisingly complex causal graph might.)

    I have a story here that’s slightly off-topic, although within the remit of the [practices] tag (or [informal methods], if that tag existed). That huge causal graph halfway down the article taught and showed me that cloud-and-arrow diagrams don’t have to have a simple structure, or a clear backbone, or some kind of symmetry to be useful: you can just draw in all the relationships, and understand it in parts.

    That will be old news to many, I’m sure. But it was very helpful for me: before, I would start making a graph and get hung up on looking for some kind of structural symmetry or simplicity that wasn’t necessarily there. A premature attempt at optimizing the diagram I was drawing. Nowadays, I can throw all the connections in and study the resulting graph part by part to aid my thinking, and this works so much better for me; and it’s the graph in this article that showed me this technique.

    1. 1

      Every single CEO of any IT company wants to build software faster. Time is the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, physical activities.

      I have literally never worked for anyone with this belief. Stability, brand reputation, security, and financial correctness have always taken priority over time to market. I am certain there are very, very rare exceptions, but they rarely pass the sniff test.

      I think the whole culture around delivery speed is a natural and logical business reaction to the uncertainty inherent in a part-creative discipline like software. Anyone who is realistically concerned about such things is in desperate need of a talented manager.

      1. 5

        Stability, brand reputation, security, and financial correctness have always taken priority over time to market.

        Based on what I’ve read and experienced it seems like you’ve had exceptional leadership where you’ve worked. Can you share the company or if there’s some way to identify a workplace like this? You can ask directly in an interview but everyone claims they care about quality…

        1. 2

          the one example I think I can safely share was AMZN. (this was over 7 years ago, so adjust numbers accordingly) when touching anything in the ordering pipeline, the first question was “is this stable” and the last metric viewed was “did the order rate dip”. when you are processing 2k - 20k orders/second and the average user won’t retry after a code 500, a 60 second outage could cost a million bucks.

        2. 3

          Totally agreed. If a CEO wants speed and you explain the trade offs that will be made, if he/she still wants speed, it’s then a matter of strategy. People are not all evil and when you explain them why quality is a cost, they understand it and from my little experience, play with it a few time and find the right gauge.

          I listened recently an old Devops café podcast that was talking about this issue, and the interviewee explained that they put a speed scale on the wall for the Product Mangers, explaining that faster is possible, but it has some costs, but let the PMs change the speed. Interestingly, the PM understood pretty quickly that being >80% wasn’t a good idea.