Barney's Rubble
Redmond Reset
Doug Barney poses the question to Microsoft developers: Is bigger better?
In the golden days of software, relatively small groups of developers built market-changing products. Microsoft has had its fair share of breakthroughs. While far from perfect, the original Word, Excel and even Windows were all based on a clear vision and crafted by tight teams of coders and product managers.
Think back to ground breaking apps. Each had a single brain behind it—Lotus 1-2-3 had Sachs, Notes had Ozzie, CP/M had Kildall, dBase had Ratliff, Netscape had Andreessen, the Mac had Hertzfeld, and Basic for the Altair had Gates. This is when software was an art driven by personality and inspiration—programmers who became superstars.
Now Microsoft has 59,947 employees—give or take—and refuses to release a product until the lines of code reach well into the millions.
Complexity is the name of today's game. More features mean more money, and all these gimmicks give sales folks plenty to crow about. Big companies think everything important has already been invented, and all that's needed is a few hundred more features.
Some products are complex by necessity. CRM, ERP and supply chain software must adapt to countless situations and data in every shape and form.
But who decided to make every other form of software infinitely complex? Is it the marketers looking for the longest checklist, executives hung up on market caps and share prices, or technologists eager to invent something new, no matter how trivial.
Think about this for a second. How many of you noticed that I didn't
mention customers?
Microsoft's obsession with complexity came back to bite when it was recently revealed that the Longhorn client was hopelessly broken. The code was simply too complex and bug-ridden to ever properly work, forcing Microsoft to scrap the chaotic code and start again from scratch.
There are troubling questions to ask. Is bigger better? Is breadth of features more important than depth, stability and usability? And who decides what should ultimately be built? I'm all for visionaries who lead the market with new ideas, but there is another wiser approach. Let buyers drive the design of the software they're expected to buy.
So does Microsoft
listen to customers? Absolutely, more than almost any vendor I've ever seen. Nobody has barnstormed more user group meetings than Bill Gates, and Steve Ballmer is no slouch when it comes to close customer contact.
I'm just not sure how much Microsoft bases products on what it hears. The company should formally and publicly engage customers in the design process—sort of an open source front-end to a commercial project.
Microsoft shouldn't worry about
the public disclosure of features under development. If you build exactly what customers ask for, chances are they'll buy it.
What advice would you give Microsoft developers? Let me know at [email protected].
About the Author
Doug Barney is editor in chief of Redmond magazine and the VP, editorial director of Redmond Media Group.