Supermarket Software

My wife bought a custard scroll for my Saturday breakfast. I was really looking forward to eating it, but when morning came & I sat down to devour its bready-custardy goodness with my coffee, I was sorely disappointed. It had come from the supermarket, not a bakery. It had the semblance of a custard scroll, & was packaged attractively, but it was all wrong. It reminded me of the last time I bought an umbrella from a supermarket - it let me down in the first rainfall.

I fear that we too often write software just like that. We might be getting better at building & deploying, but the software quality is falling down.
One of the side-effects of agile & lean is that fast-paced often gets interpreted as cutting corners. That's simply not the intent.
Another side-effect is that if you only build what you need to satisfy the requirements, then you'd better make sure that you articulate your requirements thoroughly - & then align them with what gets created, through demo & review.

I don't think there's anyone in the supermarket who is taste-testing scrolls or opening umbrellas. They're in the business of selling stuff, not providing a quality service.
This is why we shouldn't be treating software development in that way - software is a service to your business or else your customers.
It shouldn't have designed obsolescence unless that is a specific requirement; & yet too many people build that "feature" in but saying "it will never need to do ..." without actually thinking about the use of the software. In fact, software developers don't really know what the software might be used for, & have to hold themselves back from thinking of code re-use.
Product managers are the experts, using their knowledge of the market, their audience testing, etc.

Software shouldn't go onto the supermarket shelf (be deployed) unless the product manager has tasted it & is happy with the flavour & texture & utility of the software product. I'm not just talking about BAs & testers performing another series of processes that follow the requirements, but that higher level of understanding of what the software is meant to do, relative to its consumer base.

Sometimes, we fall back on the waterfall approach & say "well, that's what you asked for, & it's too late to change", or "that's all we have the budget to deliver". In effect, you're just selling those umbrellas that only open once. It's definitely not agile.
It hurts the company's reputation & bottom line, if you're talking about a product, & it hurts the business unit's ability to deliver anything in the future, even if it's an internal release of services.

A CEO from my past once used to say "we don't have to build the Rolls Royce".
He was right - we need to build the Beetle - the product that everyone was happy to use, was reliable, & targeted at its audience. Behind the scenes, German manufacturing's precision & quality was legendary - & very successful.

We, as software developers (& I include the whole development process here) have the responsibility to work like a bakery - taking care of each masterpiece we create - rather than like a supermarket pumping out software-like things in neat packages because it's cheap to do so.
A good bakery never goes out of business. A supermarket often has to heavily discount its unsold product.