In a den of lions when saying this, but companies that do that have too many engineers.
There's a "right" size for any project and going over it's hard to avoid over-thought, over-complicated, user-confusing, pedantic, semantic things.
This isn't the trite "too many cooks" argument. It's that the right kind of quick-and-dirty shortcutters who value leaving things alone produce better products; they use simpler paradigms and abstractions, have better combinable primitives, communicate purpose more effectively, and produce overall better tools.
The corollary is the stupid thing you can hack to do what you want is often better than the smart thing that is very carefully designed to do what you don't - because one of them you can technically use and the other you can't.
This is why earlier versions are frequently better than later ones and earlier products seem to do more, better, and faster. It's why smaller companies seem to produce better things, and counter-intuitively, products that take less time to finish (say a few days) seem to do better and gain more traction then the 6-month effort.
Some things really are profoundly complex, like databases and operating systems. Most things however, despite much we'd like to pretend, are not in that class of software.
And yes, these claims are cultural bomb-throwing. But the evidence for it is solid.
I think it's just as easily a sign that you might have too much or too little of a marketing department. Too much marketing influence and they create busy work for themselves like rebranding your existing products every year or so to keep them "fresh". Too little marketing influence and engineers are free to build unmarketable products without clear brands or focuses, and (closer to hand to this discussion) free to ignore the built-in good will and momentum of maintaining existing brands and products.
Sure, it's easy to blame engineers for focusing on new shiny ideas and only wanting to work in fresh codebases and "new" products, but it's just as much the fault of their management and the company not trying to adequately control its own brand(s) and how its users perceive it.
I'm contracting with Google. This is exactly the kind of argument I've been tying to make to my boss for over a year but to no avail. They come up with pet names for me to express how weird they think that type of engineering is.
There's a "right" size for any project and going over it's hard to avoid over-thought, over-complicated, user-confusing, pedantic, semantic things.
This isn't the trite "too many cooks" argument. It's that the right kind of quick-and-dirty shortcutters who value leaving things alone produce better products; they use simpler paradigms and abstractions, have better combinable primitives, communicate purpose more effectively, and produce overall better tools.
The corollary is the stupid thing you can hack to do what you want is often better than the smart thing that is very carefully designed to do what you don't - because one of them you can technically use and the other you can't.
This is why earlier versions are frequently better than later ones and earlier products seem to do more, better, and faster. It's why smaller companies seem to produce better things, and counter-intuitively, products that take less time to finish (say a few days) seem to do better and gain more traction then the 6-month effort.
Some things really are profoundly complex, like databases and operating systems. Most things however, despite much we'd like to pretend, are not in that class of software.
And yes, these claims are cultural bomb-throwing. But the evidence for it is solid.