Errata and More Musings On Open Source

In my last posting I pitted open source developers against "commercial software developers." Then, someone pointed out to me that many open source projects are commercial and their developers are no less competitive than the cube dwellers at Adobe or Microsoft. So, I apologize for using such imprecise language.

Back to coding. I don't think I emphasized enough in my last post how much eating of one's own dog food goes on in the open source world.

A shining example is the Apache Foundation. Their product is rock solid because they pound it probably more than their most demanding users — I guess their deal with IBM didn't hurt either, but they were good long before that.

Some proprietary software companies have tentatively gotten some of their developers to go into the trenches and observe their users in a natural setting and/or become users themselves.

No only do I think this is a nice "year on the farm" experience with incalculable returns in social currency, but I think it really makes developers better at what they do. Could it be that civil engineers are so good because they have to drive on their work to get to their offices?

Imagine how much insight you would gain on the quality of your POS software if you were to spend a week operating the checkout machine a local retail outlet. Such an experience is so richly textured and layered it almost defies description, except to say that it benefits all the parties involved.

Sadly, I have seen so many times cases where developers are not only not required to use the products they play a part in developing but they are almost forbidden to do so.

I am afraid we many times hurt our business through too much specialization. Not-my-department-ism is making us myopic and leading us down a path where barely have a theoretical grasp of what our software does.

In my work I have run into applications with very obvious bugs that only emerge during real-world use but are elusive to QA scripts.

Speaking of QA, we need to understand that Quality Assurance is an inexact science. As software becomes more complex and usage scenarios become more varied, the predictive nature of QA scripts becomes all the more lacking in reliability.

Real world testing, eating our own dog food, living off the land, whatever we call it is a necessary part of quality work. We need to use our products as users if we are to develop truly best-of-breed software.