• Oliver Lowe@apubtest2.srcbeat.com
    link
    fedilink
    arrow-up
    5
    ·
    7 months ago

    Getting stuff down in writing is a good step; crucial for sure. But the process/ritual of decision logs doesn’t necessarily get you great analysis or effective outcomes. Two stories:

    … or if your team uses arguments such as “let’s use X because Microsoft uses it too”, “let’s do X because everyone else does”, or “I used it in my previous project and it worked well, so let’s use it here too” then your decisions are likely suboptimal in the long term.

    I’ve read decision logs and design docs that have included this kind of reasoning. Many meetings, everyone gets their say, it’s all written down. One time, I arrived a year or two into a project and I could indeed see how exactly they came to the decision that they did. The problem was that the reasoning was super weak. Over-emphasis on process, little on problem solving skills.

    Other teams I’ve been on were fantastic problem solvers but super sloppy. If the right people were around, in the same room, they could solve things more cleanly in a fraction of the time of some company 10x the size. But for new staff, or if those key people were not around: chaos!

    I guess my conclusion is that effective decision-making comes down to balancing a whole bunch of different behaviour.

    In short: software is tricky.

    • vitonsky@programming.devOP
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      Sure, decision logs is just a step to fix a problems with decision making. Logs highlight a problems in decision making process and let you analyze a problems in your team. You still need an strong architect who may say “hey team, why your arguments so weak? it looks you are low skill engineers. make arguments more objective, or you will be fired” and then really fire weak engineers in team.

      • Oliver Lowe@apubtest2.srcbeat.com
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        Logs highlight a problems in decision making process and let you analyze a problems in your team.

        Yeah good point.

        In that process-heavy project I joined, I could quickly see the problems; about 2 or 3 days. That meant when I was submitting code or reviewing the backlog I knew what kind of challenges I could make, and what would just be a waste of time. In others, it could take way longer - months! - to learn how the team actually deals with challenges and design.