Nov 02 2006
Some months ago, when deciding how to structure a software development project team, I lamented (offline) that what I’d really like the project to resemble is a marketplace – a community of developers all eager to find their niche. As the market clears, each developer would end up doing what they do best, maximizing their comparative advantage while also maximizing overall productivity. We know this works well on a national scale (capitalism), but in a sense, many companies are (internally) little islands of non-capitalism. By saying a team would work this way, I mean internally, in terms of how the various parts of each project are divided up.
“TopCoder assesses a client’s needs, breaks the project into 30 or so components, and opens the design and development work to a series of online competitions. The coder with the best finished product wins “prize money,” as does the runner-up, which usually amounts to a few thousand dollars. The small pieces are “sewn” together, usually by TopCoder, and delivered to the client.”
Two issues come to mind though, one negative and one positive:
- In the kind of complex “enterprise” projects we sometimes take on at Oasis Digital, binding together the pieces in to a coherent solution, tends to be a major aspect of the work. Sewing together disparate pieces could easily dominate the schedule.
- A bunch of separate, talented developers, committing to building a system in this fashion, are likely to produce a highly modular system. It is hard to overstate the benefits of modularity in large projects.
Update… in my next 2 minutes of browsing feeds, I cames across a relevant post about another “industry” far outside my expertise.
If you found this post useful, please link to it from your web site, mention it online, or mention it to a colleague.
One response so far