JP writes: Time to rethink Fredrick Brooks? (Full disclosure: I used to work for JP, many lives ago, many steps removed…)
The Mythical Man Month is my favourite book on software development, bar none. I first read it years ago, in college. So initially, it was quite out of my context, but the more I experienced working in the software industry, the more I saw how true it all was!
So while we may be on the way to mitigate a lot of what Fred Brooks said years ago, I’m not sure if its time to completely overhaul the picture.
The Mythical Man Month: We do indeed prefer to develop software in smaller teams. However, social software is hardly the pancea to human communication… or, dare I use the word, empathy. Tim Bray asked earlier today, in the context of real life social networks, why do we need computers to help us with this?
The Second System Effect: I see second system effects not really with companies, but with people. So yes, while Google or Skype or eBay or Amazon may not have experienced the second system effect as organisations, I’m sure they’ve had to beat a few of their architects or developers over the head to ensure that. Plenty of open source software, I reckon, also displays the second system effect.
The Manual: This is where I see the biggest disconnect with Brooks. He was talking about building Operating Systems on evolving hardware designs. So for him, manuals were about bus architectures and instruction sets. Not sure if we can draw conclusions either way from there to the web.
Project Estimation: I believe here JP envisages an Utopia which we all want to achieve, but so long as appraisals and contracts and SOX exist, have we any chance of achieving that? So while we may have development teams that work in this way on a day to day basis, the elephant never really leaves the room. This may be the one aspect of enterprisey that we cant work our way against. Or have’nt I seen the fun stuff?
Jon Udell talks to Andy Singleton about building global teams .
An interesting ‘listen’ in general, but one of my first comments was on how these teams “wield open source componentary”.
I’ve seen how, over the years, as open source toolkits have matured, the benefits to distributed teams have been immense, and direct. Built without the assumption of co-location, geographically or temporally, they were immediately useful to any kind of distributed teams. Even simple things like how CVS is so much better over a WAN link than most older version control systems. Or that most tools were built with a web interface, making them easier to deploy access over heterogenous networks.
A succint example of what I am talking about is Collabnet, which started by packaging and supporting many of these tools in commerical environments
One emerging phenomena in this space is distributed version control systems such as bazaar-ng that take these concepts to quite another level. It will be interesting to see how these tools evolve in commercial environments.
But the connections go beyond just tools. To look at how to run a distributed agile project, a good starting point is to see how agile processes map to open source projects. That however, is a topic for another day.