Like all over-generalizations, this one has problems too. Sometimes a change is a build-breaking change and needs to go dark for a little while.
An internal API change (in a non-OO environment) is a good example. If you can’t just overload a method and publish another interface and do the work on the live code, then it can take time to hunt down and find all of the calls, make the appropriate changes, check the builds, and re-write the unit tests.
“Often going dark points to a larger problem.” --RAnonB
Indeed–or to a larger reality: it’s not just politics or insecurity that motivate dark development. Going dark may not be a symptom of a development health problem, but rather a normal characteristic of the beast.
The contrarian in me wants to point out that virtually (if not literally) all the major successful open-source projects emerge from dark origins: SourceForge is a graveyard of ‘let’s get together and build X’ projects that never go anywhere, because projects without substantial pre-existing code bases and (hopefully) benevolent dictators universally die–either by neglect or endless argument.
By contrast, all the major stuff (Linux, mySQL, etc.) generally first walks out into the light of day as a fully realized version 1.0–the product of one developer or small development group having ‘gone-dark’ for a very significant period of time. And the same is true of Ruby, Rails, DotNetNuke, etc., etc. To a significant degree, the magic (the vision, the core design, the first code base) always happens in the dark.
SO to cite the agilist principle of preferring working code to process, there does seem to be a good case for saying that going dark may sometimes be the best possible thing to do. Nothing sells an idea/approach like working code.
But of course, that’s not the entire story. I suspect that a great deal depends on the relative percentage of engineering code (defined as “employ well-understood design patterns and best practices to meet a well-understood requirement”) vs. RD code (“I want to build a better X, and I’ll know what X is and what ‘better’ means when I see it”).
Committees and communities do engineering very well IF they share common goals, values, and technical perspectives. But even in the best of circumstances, they generally don’t do RD all that well. Not to say that RD by committee can’t work–just that that’s not the way to bet.
So ISTM that there’s nothing wrong with going dark, anymore than there’s anything wrong with continual review/commit cycles. The difficult thing is knowing which is the better course at any particular conjunction of project, deadline, developer, political context, business context, technical context, etc.
bobD