Monday, August 31, 2009

I finished reading Eric S. Raymond's The Cathedral & The Bazaar (catb). Just a couple of points I want to metion:

- Raymond makes a critical distinction between sale versus use value. I think this is the seminal point in the book. Closed source software that derives most of its value from sales price. Providing technical support eats away at the sale value so it's fundamentally in the interest of closed source companies to limit technical support for at given sale price. In other words, the ideal situation for closed source software companies is for people buy their software and never use it. In contrast, open source derives most of its value from use. The business model of open source companies is centered around support. The more people use the software, the more support resources that will be consumed which benefits these companies that center around support.

- Raymond is not as hardcore open source advocate as I assumed. He does acknowledges places where open source would not be suitable.

- Open source excels in domains where software is a commodity, e.g., infrastructure such as operating system, middle ware space, browsers.

- Open source development is analogous to academic peer review. I would what would Raymond say about more artistic work?

Raymond's writing style is like that of a hacker: It may not be pretty at times but he gets his point through. There's plenty of self-citation which hurts the credibility of some of his arguments. Overall, I'd recommend reading catb primarily as a historical reference. Those of you aware of the open source revolution probably will not benefit much from it. I think it is a must read if you want to start a business centered around open source.

Saturday, August 1, 2009

Lean start-up is not limited to your traditional start-up company. Rather, it can also refer to a small department in a large company. Essentially, the speaker, Ries, believes that an effective lean start-up can be boiled down to rapid releases. Ries suggests a couple of techniques to get to rapid releases. One of the more radical technique is continuous deployment where source check-ins that pass integration tests are deployed automatically. Of course, there would need to be a mechanism in place to revert back quickly. Ries also describes split testing where new features are tested in parallel with existing code, essentially a control and experimental group comparison. Ries also recommends asking the 5-why's on every issue (e.g., asking why did this bug occur 5 times at different level from the programming level to the management level).

This talk is worth the hour if you are interested in improving your development process.

Ego (aka About Me)

I am a software developer with about 6 years of experience in various roles such as a university researcher, independent consultant, and enterprise developer.

My criteria for good software code can be reduced to a single axiom: Good code is easily testable code. This is based on my belief that software code are ultimately theories of how a business process should work. And it is well-accepted in the scientific community that good theories are testable theories. So, good code is testable code.

I hate the word "enterprise" even though I use it quite a bit.

This blog is written for the sole purpose of shameless self-promotion. :)