Perhaps a lot of products needed bug fix campaigns because most corporations tend to reward SWE productivity based on so-called "evidence" like:

- KLoC

- # of commits

- adding features

- so-called "impact"

, rather than:

- reducing the cost to maintain code

- making code more robust

- making features actually work as users expect

- rip-replacing what shouldn't be salvaged because it's too expensive

So instead of adopting a funny mustache and making inflexible commandments, it would be less disruptive to have targeted bug fix campaigns where needed to boost nonfunctional requirements like quality, reducing support costs, and improving user satisfaction to their desired target levels.

https://www.macrotrends.net/stocks/charts/CSCO/cisco/stock-p...

I don't mean to take away the truth of your experience or dismiss that you might better know the disconnect between what you describe and what outsiders might see in hindsight -- it's just the disconnect itself that's fascinating.

> If only things were so simple.

Indeed!

Part of the challenge in a "freeze spec" approach implicit in "only fix bugs" is that it assumes the market requirements are well established. That was definitely not the case for Internet protocols/functionality in 1992. HTTP traffic did not exist yet (along with a couple of dozen other things that would quickly become dominant by 1997.

The effect of the bug fix stall was to give our more nimble competitors more growth and more runway. The fact that Cisco did very well was despite the "just fix bugs" mandate.

I offered the story because I thought some folks reading the linked post would find it unbelievable that a company would decide to fixate on a single simple metric when operating in a complex and evolving environment.

Though: version control ... 1992 ... haha.

Hey, that's when that unwieldy behemoth ClearCase was released.

Tell me more about how you would subscribe to a MS "bugfix only channel of updates" ? This is my first time hearing about that.

Isn't that what's meant by LTS?

Who was competing with Cisco in 1992? I struggle to remember. They were so dominant in the "dotcom" era (late 90s) that it felt like they were the only choice, the "IBM" of enterprise networking hardware.

Incompetent management is something of the norm in software engineering. Large successful companies have a deepish management hierarchy (4+ levels) and the competence of the org is capped by the least competent manager in the chain - who tends to be nontechnical and confused. Small companies have the ability to be more competent, but correspondingly tend not to have the resources to be influential players in the market.

I would expect that typical - maybe even above average - performance by software companies is accompanied by some breathtaking stories of management failure. If it were possible for a company to not make any mistakes in its software development it'd probably be a never-before-seen fountain of wealth creation.

I'm wondering what things are like in the alternate universe where OS/2 became the dominant PC OS instead of Windows.

Paul O’Neill famously did exactly this at Alcoa starting in 1987, focusing solely on worker safety resolved many other problems and multiplied profitability.

>The company's market value increased from $3 billion in 1986 to $27.53 billion in 2000, while net income increased from $200 million to $1.484 billion.

[0] https://www.forbes.com/sites/roddwagner/2019/01/22/have-we-l...

I think it makes a very good story that a focus on worker safety--to the exclusion of any other objectives--is all that you need. But I don't think anything is that simple.