Quality can also become it's own trap as the entire org chases metrics aimed at quality. Soon you have loads of brittle tests that likely aren't adding great assertions but you have code coverage.
Because that doesn't work soon you keep adding layers upon layers to reduce the risk and your time to delivery suffers.
All knobs have consequences and long term they can really compound. The balance of picking quality over features isn't something I've seen done amazing. I'd like to work somewhere that could pull it off.
You are right and the biggest asset here are executives and management that can:
1. Think
2. Know what is going on.
3. Effectively get the best from their people.
You want the whole org to engineer the right solution
Any metric that gets abused needs to be found and replaced. Companies should use metrics and be very respectful, curious and also suspicious of them. Even revenue!
I know companies that leave revenue on the table for strategy.
Finally quality is about probabilities. That test you wrote that takes 12s to run and flakes 0.1% adding 10 hours of build time a year ... what is the probability of it detecting a bug and what would the cost of that bug be. You need every engineer to think of that stuff. It is hard stuff to get right or even good.
I worked at places where a religion almost builds. People are hired to maintain those slow expensive unreliable tests! You want to improve that you now have politics!
How do you build 1 and 2? It seems so simple: talk relentlessly about what you’re trying to do as a company, and then figure out how to assign your people most effectively to do that. I’ve seen a number of leaders figure out the messaging and then flat out fail on execution. Once they’ve worked out the vision, they fail to give middle management enough latitude to accomplish it, and the lack of trust flows downhill.
I agree. First step I think is to start measuring what’s important at the top of the organization. When you have weekly progress meetings with the CTO and CPO and only look at lists of new features, then new features will be what people think about. “What gets measured gets done”, as they say.
I have never seen positive impact from turning the devops dial up. Most of the times, we just keep on adding checklist items for quality and engineering practices. Devops keeps pushing things like observability and standardization through complex things like service mesh which creates all of its own problems.
> "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost"
Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?
> If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do?
I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning.
Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.
> A feature that drags people over is really a new product.
But isn't that a post-facto observation? I mean, any project can work on a complex feature that's a flop, but sometimes a simple feature can go a long way and just tilt the scale. That's not a new product.
Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead.
If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer your users more of the same. If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.
Time to market matters. A lot. There is no such thing as time to empty backlog.
> If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.
In the short term. Features can attract new customers but software that is frustrating to use due to a lot of low level bugs will repel existing customers towards competitors over the long term. If you've simultaneously decided tech debt isn't worth addressing then your competitor can easily overtake you. Furthermore adding feature after feature eventually leads to a kitchen sink product where potential customers are put off by the learning curve. This is really just a variation on the quantitative fallacy that ignores qualitative aspects.
"Our customers prefer the product works over getting a new feature, so let's ensure that at any cost"
Number of features is a dial. You turn that down. You turn the operations (devops) dial up.
There is nothing modern about releasing half arsed shit... we been doing it since the dawn of civilization.