Review of "The Principles of Product Development Flow"

There's a fascinating review of Donald G. Reinertsen's The Principles of Product Development Flow over at Eric Ries' blog, Startup Lessons Learned. Eric does a great job communicating the idea of the book (which I think I'll be reading shortly) and actually sums up one of Reinertsen's points in such an elegant way that I'll repost it here:

"Many of the startups I talk to - and their boards - seem to equate ability to "hit the schedule" with competence and productivity. Yet timely delivery of new features often comes at the expense of agility, especially if cycle times are long. That is often a bad trade (although, as I'm sure Reinertsen would hasten to add, not always!). For example, many startups would do better by removing buffers from their schedules, embracing the variability of their delivery times, and reducing their cycle times."

I couldn't agree more. A company with productive, motivated developers who are excited about a project might be able to reduce wasted time and work on smaller batches by encouraging somewhat flexible cycle times. "Might" is the operative word here. The thrust of Reinertsen's book seems to be that there's no way for a company to know if this is a good trade off without being able to measure, in economic terms, the cost of variability vs. the cost of longer development cycles.

WePay

I just got an invite to Wepay.com, an easy (looking) way to manage pools of money between friends. I can't wait to try it out. Look for a review in a week or two. If you want an invite, send a DM to @wepay on Twitter - they seem to be very accomodating.

Release Management

Interesting discussion in progress on Slashdot regarding release management, spurred on by this video of Theo de Raadt explaining the release process of OpenBSD, which has apparently released every six months to the day for almost 15 years.

I like Raadt's nomenclature - referring to the process of releasing as "Release Engineering". I think it much better term than "Release Management". There are enough scientific principles (repeatability, hypothesizing), quantitative measures (smoke tests, bug counts, code churn, test coverage), and tools (source reports, test case management, unit testing frameworks) to land the process of preparing a release squarely in the realm of engineering.

Overall OpenBSD's track record of stable releases is incredibly impressive, even if I question some of Raadt's practices (randomly locking the source tree, punishing developers by freezing them out of the source tree). I admire the regular release cycle and the single-mindedness it takes to make that happen. There are some interesting ideas here, but I (selfishly) wish more of them applied to typical corporate projects instead of specifically to open-source.