4 ms·

This is a really interesting anecdote because (obviously) Cisco fared quite well on net over the last severl decades, is largely respected as a reliable vendor

This is a really interesting anecdote because (obviously) Cisco fared quite well on net over the last severl decades, is largely respected as a reliable vendor for critical infrastructure, and doesn't evidence even a hiccup in market assessments of its health during that time. https://www.macrotrends.net/stocks/charts/CSCO/cisco/stock-price-history 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!

skmurphy 3y ago
The renewed growth and increasing customer satisfaction--and our long-term success--were due to engineering abandoning a poorly thought-out policy before it crippled us instead of merely hampering us. 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.
- kazinator 3y ago
  You have to do both, on different branches. Rearchitect things in one branch, fix nothing but bugs in another. Forward port all the bugfixes you can from one to the other. Though: version control ... 1992 ... haha. Hey, that's when that unwieldy behemoth ClearCase was released.
  - pjc50 3y ago
    I think that approach would be doomed even in the present day. Multiple "legacy" release branches is very hard to manage. Only the very largest such as Microsoft can do it, and they clearly hate doing so and want to push to rolling releases like everyone else.
    - worthless-trash 3y ago
      Red Hat / RHEL does this on all EUS release every day, on RHEL 6,7,8,9. Tell me more about how you would subscribe to a MS "bugfix only channel of updates" ? This is my first time hearing about that.
      - pjc50 3y ago
        > bugfix only channel of updates Isn't that what's meant by LTS?
        deleted 3y ago
        [deleted]
        worthless-trash 3y ago
        Do you just 'install' the msi, and then thats LTS ?
- pjc50 3y ago
  > our more nimble competitors 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.
roenxi 3y ago
> Cisco fared quite well on net... 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.

skmurphy 3y ago

The renewed growth and increasing customer satisfaction--and our long-term success--were due to engineering abandoning a poorly thought-out policy before it crippled us instead of merely hampering us. 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.

kazinator 3y ago
You have to do both, on different branches. Rearchitect things in one branch, fix nothing but bugs in another. Forward port all the bugfixes you can from one to the other. Though: version control ... 1992 ... haha. Hey, that's when that unwieldy behemoth ClearCase was released.
- pjc50 3y ago
  I think that approach would be doomed even in the present day. Multiple "legacy" release branches is very hard to manage. Only the very largest such as Microsoft can do it, and they clearly hate doing so and want to push to rolling releases like everyone else.
  - worthless-trash 3y ago
    Red Hat / RHEL does this on all EUS release every day, on RHEL 6,7,8,9. Tell me more about how you would subscribe to a MS "bugfix only channel of updates" ? This is my first time hearing about that.
    - pjc50 3y ago
      > bugfix only channel of updates Isn't that what's meant by LTS?
      - deleted 3y ago
        [deleted]
      - worthless-trash 3y ago
        Do you just 'install' the msi, and then thats LTS ?
pjc50 3y ago
> our more nimble competitors 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.

roenxi 3y ago

> Cisco fared quite well on net... 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.