Collaboration or Groupthink?

Saw this was posted on Facebook by a colleague at work:
http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?_r=2&ref=opinion

The whole notion of calling out "teamwork" as such a basic value kind of gives me a chill.  Goose bumps even... 

I can't speak for you, gentle reader, but I can safely say that the absolute worst work I ever did in either my academic or professional careers was in group projects.  I can recall exactly two projects in the working world where my entire software team met or exceeded my own and our customer's expectations.  The only times I've ever been on "teams" that consistently worked were bands.  And that's only happened like 2-3 times in over a dozen bands. 

I even remember in school thinking that the best possible outcome of group work was usually mediocrity.  The usually random mix of group members and their general engagement levels meant that one or two people in the group would usually take on 85-90% of the work.  I see this pattern echoed in virutally every large company I have consulted or contracted for.

Certainly there are needs which can only be served by teamwork. Huge workloads of all kinds require more resources, which can most usefully be coordinated in teams.  Another dimension would be skill sets required for the work, which may also need to broken down team-wise.  But in terms of a need for teamwork involving more than one mind focused on a single problem (i.e. "brainstorming"), the statistics say that this usually does not result in a better solution.  Note the important exception pointed out by the author about collaboration (specifically remote collaboration, as enabled by technology).    fostering collaboration between nominally independent individuals seems to have significant worth. 

I look at this as the true endgame of the software "collaboration wave" seen in business IT right now.   It's easy to dismiss the buzzword, or consider it a forced mandate for "groupthink."  But empowering knowledge workers with data, allowing them to build ideas and evolve them into useful business tools -- that is a powerful force that is already working. 

BI Estimation - "A more appropriate metahpor"?

http://peterjamesthomas.com/2009/03/18/a-more-approprate-metaphor-for-business-intelligence-projects/

So this leads me to suggest a different metaphor for BI projects. Major elements of them are much more like archaeological digs than traditional building. The extent and importance of a dig is very difficult to ascertain before work starts and both may change during the course of a project. It is not atypical that an older site is discovered underneath an initial dig, doubling the amount of work required.

That's so obvious it kills me that I hadn't thought of it before.

Required General IT Reading

The vast field of IT books has a slew of timeless classics in it, all of which  should be read by anybody intending to be worth their salt as a technical professional.   

But in fact, I seem to encounter less and less discussion/mention of these kinds of books as the blogosphere inflates and the Tweets zip overhead.

So, a few of those in particular I wanted to mention here, as a curmudgeony sort of move:

The Mythical Man-Month (Frederick Brooks) - This is a classic about the human aspects of developing software.  You need this, critically.  Buy it now.

Code Complete (Steve McConnell) - The definitive distillation of programming style and consideration.  For your colleagues, for the future, for God's sake -- read this and absorb it if you ever do any coding.   And don't think you know better.  Because you probably don't.  Sorry.

An Introduction to General Systems Thinking,  The Secrets of Consulting,  Becoming a Technical Leader: An Organic Problem-Solving Approach (Gerald M. Weinberg) - Gerry Weinberg is one of the great unsung heroes in the history of software development.   All his books are chock full'o'wisdom for any kind of systems developer or engineer.  Not to mention his consulting expertise.

The Inmates Are Running the Asylum (Alan Cooper) -  A definitive treatise about bad user interface design in modern technology.  Must-read.  Really, this has saved me some rewrite work over the years.

Design Patterns: Elements of Reusable Object-Oriented Software  (Richard Helm) - A little more down in the details than the rest of these tomes, this one is valuable not just for the specific patterns described, but for illuminating the whole idea that there ARE patterns in the software game...

 So check these out.  All of them definitely affected my thinking and behavior over the course of my career -- in positive ways.  Next time, some more specific BI and Consulting book recs.