Posts Tagged ‘Freeze (software engineering)’

New Version Every Other Week for Three Years?

February 16, 2011

I get up every morning determined to both change the world and have one hell of a good time. Sometimes this makes planning my day difficult.

E. B. White
US author & humorist (1899 – 1985)

Releasing a working version to customers every two weeks is fun.

  • It is fun for customers who use the features instead of watching fictitious  “product road maps”.
  • It is fun for developers who see their work is actually used.
  • It is fun for the executives who can change the business priorities quickly.
  • If is fun for product managers who can measure actual usage.
  • It is fun for the R&D manager ,as the problems can not be hidden for long.

In my company,  we delivered 72 versions to customers  in three years.

Programming in the large and programming in th...

Image via Wikipedia

Here is one way to do it:

  • Hire top talent for development , QA , IT and operations.
  • Deliver the product as a Service (SaaS). Upgrading one instance is much easier than upgrading 10,000.
  • Bi weekly synchronization meetings on Monday and Thursday. Monday is just team leaders and Thursday is all of R&D.
  • Invest early in QA automation. We invested $20,000 in Automation infrastructure at a very early stage.
  • Invest in Unit-Testing as much as possible.
  • Avoid branching. Branches are evil. Merges are Yikes. One branch is good, two is max.
  • Invest in the “Ugly stuff”. Deployment scripts, upgrade scripts, database consistency.
  • Constructive dictatorship. Every code change  has a ticket. Every. No exceptions.Really.
  • First week is for coding. Than it is feature freeze. Three days for QA and bug fixes.Code freeze. Two days for final QA and critical fixes only. Release on Sunday.

In the next post I’ll try to answer the tricky questions: What about longer features? How not to scare the customers? and more.


Follow

Get every new post delivered to your Inbox.

Join 195 other followers