New Version Every Other Week for Three Years?

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.

Tags: , , , , , ,

7 Responses to “New Version Every Other Week for Three Years?”

  1. Tamir Gefen Says:

    In other words, you’re suggesting Agile methodology … 🙂

    Referring “Avoid branching” – you know it depends on your product. You’re offering SaaS so it’s actually one instance (or COTS)…
    Vendors which offer customized solutions that are based on a common basis, cannot avoid branching. Besides, there are good solutions to resolve the branching and merging challenge.

  2. ophirk Says:

    In my previous life I worked in a very successful product company with 40,000 yearly builds and many, many branches 🙂
    The result is that many of the strategic product discussions became strategic branching discussions.
    While not all of them can be avoided, I think many can and should.
    In my (overly) simplistic view, branching, even in product companies, stems from
    * bad coding – not modular enough
    * wrong business decisions – customized projects instead of configurable products
    * lack of ownership – too many people touching the same source file

    And last, but not least, managers who are too afraid to kill projects or move them to the main branch.

    Branching, like tomatoes, is evil 🙂

    Regrading Agile – I don’t like the part of “No Documentation” and “No Processes” , but I believe the other principles are pretty strong.

  3. Tamir Gefen Says:

    I know where you had worked…

    I totally agree with you. You have to branch only when you have no better choice.

    I do agree with you regarding the “No Documentation and no process”. I know that the Agile manifesto may be changed soon.
    Do you know we provide a tool that supports automatic documentation for Agile iterations? It also provides “who is the ownership” information. Recently we’ve delivered a webinar in the US about it:


  4. Guy Says:

    Great Post.

    Agile like any other religion has many branches and different preachers.

    I do think that the “One God” moto that is common to most of them is the “Release often” to satisfy the true God of the customer/user.

    Regarding the rest, I believe that we can discuss the practice, which is based mainly on the tools you have. For example, if you have a good tool to write “Executable Specs”, you will have much less “Text Spec Documentations”.

    This is why I’m interested in the 20K automatic testing tool that you invested early on. What was it, and how much do you really use it?

    • ophirk Says:

      thanks Guy. For a list of tools see my blog post at

      for the automation we had a project with Aqua software. We paid them for their experience in QA automation projects. The project is still used successfully today and is developed by a full time automation developer.

      As for the automation tool, we actually used the wrong one. Instead of using Aqua’s solution we forced them to use Microsoft products which turned out to be quite bad. What we are using today is the same architecture, but written on “RAW” C# with open source tools for browser interaction.

  5. Ethan Ram Says:

    Hey Ophir. interesting reading!
    The current trend in this field is development in Kanban workflow where every feature is a release candidate and Continuous Deployment where new code is automatically tested and deployed to staging and even to production servers on a regular basis.
    check this one out – imvu is pushing code to production 50 times a day!
    and are pushing code to production 16 times a day-

    we started moving is this direction a couple of months ago, post our first major release. we’ve canceled the concept of major releases completely. already managed to cut development cycles from 1-2 months to 1-2 weeks and deployment cycles from 10 days to 3-4 days. very exciting.

    • ophirk Says:

      Thanks Ethan, you seem to be in the right direction.

      Continuous is a great model to desire, but what works for consumer sites may not work in enterprise scenarios:

      * Database upgrades are a challenge. Having separate tables for each customer is not always possible\ efficient (wordpress)

      * Data model changes are very dangerous. Having an automatic script to deploy and “revert on need” (IMVU) only works for code changes

      * Some times mistakes are found in a few days delay. Partial reverting can be quite hard, especially if customer have already used enw features and data was changed.

      * Some things just take a lot of time to test (e.g. memory leaks). Testing them in production has some benefits, but the monitoring tools have to be amazing.

      * Writing automatic tests for SQL queries is very very hard. Keeping them updated is even harder. I’m still waiting for to find a good solution.

      * Even with Selenium, some bugs require a human to notice (Usability, Performance, User Interface,Browser Compatibility ). For wordpress it might be OK that end user report these bugs, but it’s not not for every project.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: