Software development is a young discipline. As such, practitioners and managers try to use techniques from other disciplines to control and improve it.
There is a wide variety of analogies that people use to think about teams of software developers:
This model is based upon that of a surgical team. A "chief programmer", like a chief surgeon in a SurgicalTeam
, makes all the decisions and does all the important work, while the rest of the team provides specialized support.
The downside of this model is that the success of the team is very dependent upon one person.
This model, favored by many managers, treats software development as a manufacturing activity. This is attractive to managers, as they can use manufacturing management methods to attempt to monitor and control the activity. Developers tend to dislike this model, as it treats them as cogs in a machine.
Managers like this model because they want to be able to measure things and to use those measurements to predict outcomes. For example, if they think that a software project will require 100,000 more lines of code, and the team is producing 500 lines of code per day, then the managers can predict that it will be complete in 200 working days.
Unfortunately, this does not work well in practice. Use of statistical methods for measuring and predicting productivity tends to work only for very large teams. See ProgrammingAintManufacturing
See also AnalogyBetweenProgrammingAndManufacturing
(which takes a broader view of both programming and manufacturing than this straw-man "Assembly Line")
In this popular model, software is designed by "architects" and built by skilled craftspeople.
has a good description of this model.
See also SoftwareArchitect
Actually, I'd say it's becoming more and more common that software is designed by "architects", built by "labourers" with a few "skilled craftsmen" contracted in to handle some of the detail. See SoftwareLabourers
Many developers like to think of themselves as "engineers", like electrical engineers or civil engineers.
In reality, SoftwareEngineering
is not much like other engineering disciplines. Some believe that this is simply due to the immaturity of the industry, but others think that software development is just not well-suited to engineering-style discipline.
A Couple of People in a Garage
In this model, a couple of smart people work together with little or no oversight. Often, only they have any idea what they are doing: no managers are involved at all. Some very successful companies and products have been launched by teams such as this.
This model does not only apply to small startup companies. The InventorsOfUnix
fit into this model, despite the fact that they worked for a mega-corporation.
See also GarageShopEnterprises
In this model, well-respected people are brought in to complete a project. They often have little or no oversight from management - all that matters is that the people are known for producing results.
See also CowboyCoding
Here, the leader is seen as a conductor who organizes all the workers such that they work in harmony. Sounds nice, but is not very much like reality.
Why not? It's a classic project manager + project team members organization. It's also pretty much the way I run my team - but we do infrastructure engineering, not software development
Well, I've never worked with a symphony orchestra, but I assume that there is a cycle of "rehearsals" and "performances". The real work of the conductor is to interpret the pieces and give instructions to the musicians during rehearsals. At a "performance", the conductor doesn't really do much (in comparison to the non-performance work).
Well, yes, if you take the analogy too far then it's clearly not accurate. A software development team is not an orchestra. But a central coordinator (conductor) who arranges that all the developers (musicians) are working from the same song sheet is a valid model, I think
To make this a metaphor for software development, the conductor would be the "technical lead", and the "musicians" would be the development team members. Maybe some analogies can be drawn between "performance" and "software delivery". But I don't think the overall model works very well as an analogy for software development, for these reasons:
- The individual musicians in the symphony have little effect on the overall product.
- A symphony orchestra doesn't have long-term "projects"; its cycles are very short and are unrelated to one another.
- An orchestra plays a piece of music written by someone else. They don't have the opportunity to re-write (re-design) the piece; they are constrained by the notes on the pages. And a conductor can refer to how others have interpreted the same piece. In contrast, a software development project tends to be unique and under constant re-design.
And programmers generally look silly in tuxedos.
See also SoftwareDevelopmentComparedToJazz
In this model, the technical leader is seen as the "director" of a movie, and the development team is the "crew". The project manager is the "producer". The system architect is the "script writer".
Movie production is similar to software development in these ways:
- The director makes the creative decisions; the producer makes the business decisions.
- The crew is a set of skilled craftspeople. And many of those crewmembers can make significant creative contributions.
- A project lasts for a long time, and has several phases: pre-production, production, post-production, and release.
- Re-writes of the script are common, there's a lot of editing, and the final product doesn't always match the script.
It is not similar in these ways:
Maybe I'm reading too much into this analogy, but where does the
- Movie crewmembers are not interchangeable. A cameraman wouldn't temporarily fill in as a sound editor, for example. In contrast, software developers are less specialized.
- There are no opportunities to fix problems with a movie after its release. (Sure, there are "Director's Cuts" and re-releases, but those are the exception.)
- Most movies are created for a mass-market audience. Most software development is highly customized for a small group of users.
cast of the movie fit in?
I intentionally made everyone "crew" to avoid the problem of treating actors as special, due to their celebrity status. I suppose you could look at computer-world celebrities (BillGates
) and gauge how they affect the products their companies create. But that's another difference between software development and movie-making: most software customers don't "see" any of the team that produced it. -- KrisJohnson
See also InsideTheActorsStudio
But if you are on a computer game project, you will find the Movie Set analogy very real. Here you have a creative director, a producer, sound desingers, actors (for motion capture and voice), graphic artists, script writers and the coders filling a role in and of itself. The coder are not easiliy interchanged with other disciplines, although specialized under themselves (3D-wizard, toolsmith, networking, in-game UI, etc). Also you develop for a mass audience (at least you hope that it will be so :) and usually only ship 1 version of your product with or without possiblitiy to deploy patches (dependent on target platform).
Cowboys in a Cattle Drive
The odd thought that occurred to my one day driving to work. No one succeeds unless they all succeed. People have roles but often switch. A lot of normal daily activity with periods of intense crisis. Well-planned in advance but the reality is much more chaotic. Gets most of the herd in on time but may lose a few head (requirements) along the way. -- HowardFear
See also DevelopmentStance
See also CharlesWeir
's paper PatternsForDesigningInTeams
Note that there's an AnalogyFest
event at AgileDevelopmentConference
devoted to this topic. (This paragraph is fresh until June 7, 2003.) --BrianMarick