My Finetix colleague, Chris, just reminded me of the lunchtime conversation we had a few days ago with one of our good friends from RiskFocus. It got me thinking about an interesting model for development.
Think of what a General Contractor does when you do construction on a home. He gets (hopefully) the best-of-breed specialists to perform certain functions. He has one company to do the foundation, another to do the framing, another to do the electrical wiring, and another to do the sheet rock and spackling. Each of these tasks is done efficiently by the tradesman, and then it is understood that they move on to another construction job.
I am wondering if anyone has followed this model in developing systems. A "General Contractor" gets the best consultants around to perform a specific specialist task, something that they do best. The job lasts for one month, and then the contractor moves to a different development job. There would be a specialist to write the framework, a specialist to plug in the security and entitlements, a specialist to write the Web Services and fix any interoperability issues, a specialist to write the calculation engines, and then a GUI specialist to plug in a front end. Each member of this well-oiled team would be versed in the various interfaces and abstractions that the other members of the team use, so that the security specialist would come in, and know immediately where to hook in his stuff to various parts of the framework.
The members of the team would rotate amongst the various specialties so they do not end up getting tagged as a master in only a single discipline.
I have never seen this model being used, but I would be curious if anyone has ever tried it.
Your comments are welcome.
©2005 Marc Adler - All Rights Reserved
Subscribe to:
Post Comments (Atom)
6 comments:
I can see independants being hired by banks to perform this model. Where I work (JP Morgan) we have hired Java performance specialists to tune certain applications (1-2 month assignments)
IMO, using such an approach would be awful. The potential to end up with a pile of Sh** is huge. Building software is not the same as building a house. Software is like play-doh, you can continually massage it into whatever shape you like.
Damian,
Do you think that it would be more akin to building a house, and then letting someone decorate the interior in whatever style they want? In other words, would a model work where a General Software Contractor would come in, built version 1.0 of the app in a cookie-cutter sort of way, and then let the client take over the "interior decorating" (ie: molding the PlayDough)?
By the way, I am neither for nor against this approach. Just wondering if anyone has thought about it and done it. Certainly, a company like ThoughtWorks, with its vast array of specialist talent, is a prime candidate to experiment with a concept like this (although it is probably against the entire ThoughtWorks model).
I see it as always moulding the play-doh. In a truely agile sense, you write the software in a way that best fits the requirements for the current story/iteration/sprint and refactor (mould) when new requirements come along or your understaning changes. This is what enables us (me anyway) to deliver stuff that does what the business wants in a timely manner. I don't really like the idea of having specialists on my team, i want everyone to understand and be able to change any line of code in the system.
Hi Marc,
I wouldn't be too keen on this approach, for a few reasons.
In theory, the analogy could work.
But consider what happens if the first contractors put in poor foundations. That might only show up when the house is finished, or near-finished. Those contractors have been paid and gone away (alright, could include a completion payment, but that muddies the issue, doesn't resolve it).
The problems of poor foundations affect all the other work on the house, increasing the costs with remedial actions, delayed completion (or worse still, a house that falls down and cannot ever be lived in).
[Think we've been on a project like that - expensive foundations, but of the wrong shape and size for the end result, so only fit for the bin]
Software teams should work together in a more co-operative manner, not a sequential and isolated style. The size of each part of the team should shrink and grow as necessary.
I guess this gets to be a comparison between waterfall development approaches versus iterative or even agile methodologies.
But you can't build a house in a fully iterative approach, if you don't know if you want a bungalow or a skyscraper to begin with, you won't put in the right foundations. That can be a problem with XP/Agile stuff, IMHO, which can lead to increased costs/delays when the point is inevitably reached when the customer/user sees the low-rise building and says that they wanted a condo - time to start again, not hack around with the wrong baseline.
Enough rambling anyway. Fair to raise the point, but not one I'd agree with.
See also write-up from Xansa, on the DSDM web site.
http://www.dsdm.org/timebox/issue28/bricklayers.asp
Post a Comment