Development Team Models

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.

Assembly Line

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.

CodeComplete 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 --JayBell


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

Hired Guns

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.

Symphony Orchestra

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:

And programmers generally look silly in tuxedos.

See also SoftwareDevelopmentComparedToJazz

Movie Set


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: It is not similar in these ways: Maybe I'm reading too much into this analogy, but where does the cast of the movie fit in? -- MikeSmith

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, LarryEllison, SteveJobs, JohnCarmack, SidMeyer?, LordBritish) 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).

Military Unit

See ArmCl, GreenBeretCoding

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, HelpYourManager, ManagersDontCode, LeadersDontDo, ManagersShouldBeDevelopers

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

EditText of this page (last edited February 11, 2007) or FindPage with title or text search