The fallacy goes something like this: "We're done with that, so let's do something new."
See, the mouse has been "done" for years. In fact, I tried to look for a replacement mouse for my old mouse a couple weeks ago, and was really unimpressed with the Microsoft & Logitech offerings. Nothing really new since 1999 or whenever cordless mice were "new". It seems like both of these companies mostly gave up. Longer battery life for wireless mice, I think? But they must have fired all their industrial designers, because now they have mice that push into a little well, so your fingers push into this sharp edge of the case, or these other mice that have back buttons exactly where your thumb goes (Microsoft's are smart about putting the buttons near where your thumb goes). Anyway, I digress.
Making software and hardware better is a bigger problem than that. Because it's about how you set priorities in your organization.
It's not all about "don't re-invent what we did 10 years ago."
Often it's even, "Don't work on something that we finished a week ago." And that probably doesn't make sense, but here's how it happens:
Management: Can we ship this feature early?
Engineering: Well, the UI's not really done, and we want to add all this other stuff to make it work better for actual users. I mean, it kind of works a little bit.
Management: Great, let's ship it. We can do all that other stuff in version 2.
And the big secret is that version 2 actually never happens. Ever.
Because, next month, compared to having a new feature, improving the old feature looks boring. It's not as easy to talk about. It's not as impressive.
But the best teams actually do the exact opposite, because they care about their product and their users. They go back to the thing they were working on last month, and finish the things they were intending to do. They go back to the thing they were doing 2 years ago, and make them better. They keep working until it's done.
And yes, this fallacy happens a lot in the Agile/Continuous Deployment models, where finishing a task means you should probably ship it to users. It was easier to hide "getting it right" in the old, slow way of making features. You have to schedule it in the newer models, and that's hard to do, but it's important.
The era of "more features is better" is ancient history in most products (it makes me think of those magic PC Magazine checklists comparing MS Word to WordPerfect), and companies that do a smaller number of features really really well, keep their users happier and win.
The first few versions of an application tend to define and establish the application's core competencies. After that, it seems an almost inexorable fact subsequent versions will pursue more and more features at the expense of refining the core competencies that were the impetus behind the application in the first place. Drives me crazy, and it's hard to think of many examples outside software where such a strategy is considered a good one.
ReplyDelete