My wife asked me if I knew about it. Water was running through the moulding framing out window. Down the exterior siding, through the seam and down the glass on the other side of the moulding.
I own a 107 year old house. There is a long list of changes I want to make. There are also repairs. I need to be careful about what I choose to do and in what order. Some repairs if delayed could result in other more expensive repairs. There are some improvements that have a high risk of creating a new issue. If I want a new plumbing fixture and I mess with the connection, I could find myself digging into the walls to fix other plumbing issues. Some repairs are “do now”. Others are “do later”. Others yet are “do never”. Deciding what to do is a cost-benefit and risk analysis. Most work will not produce the outcome we want. This is the 30-30-30 rule of agile (1/3 of feature produce the desired user experience, 1/3 do nothing, 1/3 hurt the user experience).
I’ve found that software engineers like implementing new things. Any time an engineer goes to a conference we can plan on a backlog of improvements we have to do. NOW! In most cases, the improvement isn’t needed, let alone NOW.
I’ve chased the shiny thing. I’ve come back from Re:invent with the AWS afterglow of the new panacea (Security Hub, Control Tower – heartbreak). I get the excitement. I understand the tunnel vision that is born from researching a new solution and seeing it as the great new hope.
Most of the time, we need to start with the question: “What’s the cost if we don’t do this?” “Who’s paying the price?” And follow it with “What’s the benefit if we do?” “Who benefits if we do this?” These questions tend to not come up.
We implement another new ingress controller, spending 4 weeks figuring it out including how we configure and deploy it. A single product family with 4 different security solutions built bespoke for a specific customer instead of being built for all our customers.
Just like this post, the thread, the purpose, the intent gets away from us. We forget who we’re serving and what they might want.
The first problems to solve are those that are existential. After that, there’s explaining to do. The user should benefit, clearly. Engineering teams should have the autonomy to solve problems as they see fit. They shouldn’t have a blank checkbook. We shouldn’t change the sheetrock because we don’t like the orange peel texture when water is pouring through the moulding to inside and then outside our house like an MC Escher drawing.
