Since I posted the “Free Fall” development post, I’ve been thinking a bit about the pros and cons of this type of off-release development.
The OpenStack Swift project does not do free fall because they are on a constant “ship ready” state for the project and only loosely flow the broader OpenStack release track. My team at Dell also has minimal free fall development because we have a more frequent release clock and choose to have the team focus together through dev/integrate/harden cycles as much as possible.
From a Lean/Agile/CI perspective, I would work to avoid hidden development where possible. New features are introduced by split test (they are in the code, but not active for most users) so that the all changes in incremental. That means that refactoring, rearchitecture and new capabilities appear less disruptively. While it may this approach appears to take more effort in the short term; my experience is that it accelerates delivery because we are less likely to over develop code.
Unfortunately, free fall development has the opposite effect. Having code that appears in big blocks is contrary to best practices in my opinion. Further, it rewards groups that work asynchronously and
While I think that OpenStack benefits from free fall work, I think that it is ultimately counter-productive.
