A spectrum of collaborative techniques exists between the two extremes presented below.
* A collection of independent professionals rather than a tightly integrated team.
* Each developer brings different skills to the table.
* Each developer has a high level of expertise in his or her own domain.
* Each developer works independently and largely alone.
* Tasks are defined in broad terms: Developers have high levels of freedom and autonomy.
* Development Environments are varied, idiosyncratic and highly customized.
* Git / Hg - separate repositories for separate components.
* Few inter-dependencies.
* Quantum of re-use is large: A critical mass has to be achieved before something is placed into it's own repository and shared.
Tight Collaboration leads to Fine Grained Reuse
* A tightly integrated team rather than a collection of independent professionals.
* Work carried out by both junior and senior developers.
* Developers work in close collaboration with one another.
* Tasks are small and fine-grained.
* Working Practices & Development environments harmonised & centrally controlled.
* Subversion / CVS - single monolithic repository
* Many inter-dependencies.
* Techniques like continuous integration and test-driven development keep everything on track.
* Quantum of re-use is small: individual scripts and configuration settings are easily shared.
Which approach creates a better work environment? Well, it totally depends upon your personality. Personally, I enjoy working with other people, so I tend to find the tightly integrated team approach more fun, but I am happy to acknowledge that this is not everybody's cup of tea. I must also admit that my preferences continue to change as I grow and develop.
Which approach creates better software? I have no idea. System Architecture will definitely be impacted by the approach to collaboration. In some manner. So, I imagine that the development of some particular classes of software are better served by the first approach, others by the second approach. I cannot, for the moment, imagine what the mapping between class of software and most-appropriate approach would look like.
Guesses in comments, please.
PS:
There exist other spectra on which Software Development activities may be placed. One notable one is the Predictive/Reactive spectrum, which distinguishes between predictive, variance-minimizing techniques as espoused by SEI/CMMI (Chicago School), and reactive, "Agile" techniques. In contrast with the loose/tight collaboration spectrum, it is easier to judge the appropriateness of predictive vs reactive, as level of anticipated technical risk is pretty a good indicator of the degree to which a reactive approach is appropriate.
PS:
There exist other spectra on which Software Development activities may be placed. One notable one is the Predictive/Reactive spectrum, which distinguishes between predictive, variance-minimizing techniques as espoused by SEI/CMMI (Chicago School), and reactive, "Agile" techniques. In contrast with the loose/tight collaboration spectrum, it is easier to judge the appropriateness of predictive vs reactive, as level of anticipated technical risk is pretty a good indicator of the degree to which a reactive approach is appropriate.
I've recently joined a company very much working in the Loose collaboration method. Researchers work alone, often developing complex algorithms in high level languages, which are then (if needed) incorporated into software in C++ or Assembler.
ReplyDeleteWith smaller, simple projects or modifications to existing algorithms, this can work well. Left alone, people can concentrate on small specific areas of research for a week or two before sharing the knowledge with the rest of the team.
With larger, more complex projects, i find this troublesome. Meetings, designed to promote communication between team members, become harder. As the work becomes more complex, it becomes difficult for others in the team to understand. Meetings are then resented or seen waste of time since it is difficult to gain or contribute any knowledge, further isolating people. It also becomes difficult for management to understand or direct the research, and individuals may direct their work to what they see as interesting or furthering their own CV, rather than in a direction that would best benefit the company. New hires to the team may find it very difficult to find their place and fit in with such a lack of communication. Documentation of research carried out, also becomes difficult for other employees to check or review easily without gaining large amounts of highly technical knowledge of the subject area. The company is also exposed to losing large knowledge should an employee leave.
Changing this culture i think requires strong leadership and commitment from management. Work needs to be restructured, so research is carried out collaboratively by changing subgroups of the team. Knowledge is broadened and people start talking and working together, with greater cross fertilization of ideas.
I feel your pain.
DeleteI feel it is worth mentioning, however, that if you need to get something done quickly in the short term, are willing to spend significant amounts of money to hire experienced, senior level staff members, and are happy to either stop after you have achieved your objective, or reengineer and reintegrate your system after you have achieved your primary objectives, then then loose collaboration can be perfectly suitable and appropriate.
This model is adopted by many startups, where the priority is prove the business concept rather than to build sustainable software; to focus on long term economic efficiency or to put significant time and effort into people management.
However, I would be doing my profession a disservice if I did not point out my strongly held belief that, given the right tools, together with a sufficiently high level of discipline and organization, a high-functioning tightly integrated team can (on average) out-perform a high-functioning loosely integrated team over all but the shortest timescales.
See also:
Deletehttp://ashtonkemerling.com/2012/11/27/the-myth-of-the-lone-hacker/