modrepublic

I think sometimes programmers forget how much work it is to create software at large companies. What may seem like a no-brainer five line code change to us on the outside is perhaps five man-weeks of work once you factor in all the required process overhead. We're picking on Microsoft here, but this is by no means limited to Microsoft; it's a simple function of scale and audience for all commercial software.

So then, the obvious question: who does all those things for non-commercial, open source software? The answer, per a Raymond Chen comment on the same post, is "nobody":

Who develops the test plans for open source software? Who updates the screenshots in the user's guide and online help? And who translates the documentation into Polish and Turkish? Who verifies that the feature doesn't violate the Americans with Disabilities Act or German privacy laws? Back when I worked on Linux, the answer was "Nobody. There is no test plan, there is no printed user's guide, what little documentation there is exists only in English, and nobody cares about complying with the ADA or German privacy laws." Maybe things have changed since then.

Here's my honest question: does open source software need all that process to be successful? Isn't the radical lack of process baggage in open source software development not a weakness, but in fact an evolutionary advantage? What open source software lacks in formal process it makes up ten times over in ubiquity and community. In other words, if the Elbonians feel so strongly about localization, they can take that effort on themselves. Meanwhile, the developers have more time to implement features that delight the largest base of customers, instead of plowing through mountains of process for every miniscule five line code change.

Are large commercial software companies crippled by their own process?

If you openly reward and promote people for killing work by bemoaning the risk and the testing cost and localization impact of each feature and interrogating a design change request as if it were Dan Brown shackled in-front of a wild-eyed, hot-poker wielding Pope, well, everyone is going to grab pitchforks and jump on that "No can do! No can ship!" bandwagon.

It makes me think of how many feature meetings I've had and what a small percent of those features have actually ever shipped. Not that every feature is a good idea, but it's damn near wake-worthy sometimes for a feature to actually get out into shipping bits. Que Eeyore: "Oh no. Now we have to support it. I suppose a hotfix request will come in any moment now..."

All too often, it really does feel like Microsoft's software was designed by Eeyore.

In this case, the bird represents features that delight customers.

[advertisement] Dashboard for Data Dynamics Reports introduces new controls designed to create dashboards that inform without wasting space or confusing users.