Are there good reasons for developing features in isolation when aiming for the same release target?

Question

Many developers or teams seem to want to develope there features in isolation. I'm all for continuous integration and team work and I'm having hard time to figuring out if there are any good reasons from technical perspective in developing feature in isolation.

Answer 1

• are they isolated features? are there legal / management reasons they should be isolated?
• is it dictated that they share a release target, or is it an aim? If one slips, do you want to be able to release the other? Or hold both back? (either answer can be right)
• does one (but not both) depend on external factors outside your control? the release of a 3rd-party toolkit, for example
• are they both public knowledge? perhaps you want to release a beta/preview of one but not both?

In general I'm all in favor of keeping things simple. Sometimes that means keeping them isolated, and sometimes it is easier to mix them up. It really depends on the project, the team, etc.

Answer 2

As Marc already mentioned, there can be good reasons for it. To add a concrete example, in a previous project I was participating in, we had several huge features being developed in parallel, by more or less distinct subgroups of the team. Each of these required one or more man years' effort, and involved a high risk of schedule slippage and feature creep. Some of these were planned to be released earlier than others.

This was a standalone GUI application, so all the features had to be accessible from the GUI in order to be testable, even when they were half ready only (and it is a legacy app so unit tests were a challenge). Therefore we had to create a separate branch for the feature which was scheduled not to be published with the next release yet. Otherwise we would have risked a lot of complaints from our users trying out the new GUI elements and finding that they "do not work as expected".

Answer 3

As an individual developer, I could see somebody desiring it because there are fewer hassles synchronizing their code as they go along. And, they gain the extra advantage of less oversight.

While, some individuals may see this as a benefit; in most cases, this isn't a benefit for the team. Waiting until the end and hoping that the developer considered everything has, just occasionally, gotten us into trouble.