Christine Nolan has been doing an excellent job organizing the Software Cluster of MassTLC. Today’s meeting took place in the VMware facilities in Cambridge and moderated by Brad Meiseles, Director of R&D at VMware.
Brad made a couple of excellent references and quotes such as:

• “Begin with the end in mind” – From Steve Covey’s book of the 7 habits of highly effective people as Habit #2
• “The major problems of our work are not so much technological as sociological in nature” – Peopleware quote.
• “To build a successful organization and team, you must get the right people on the bus” – Jim Collins, from Good to Great.
• “Developers prefer to user agile methods; managers prefer to use heavy methods” – Anonymous
• “Micromanagement is evil; measuring lines of code is useless, because less truly is more” Mikael Jansson
• “Developer’s productivity is really a qualitative assessment, not a quantitative measurement”

(If you Google on each of the above subjects, you can spend a wonderful afternoon with the ideas and opinions of many experts!)

Following Brad’s stimulus, the group engaged to a wonderful discussion about

• Factors that drive software developer’s productivity
• How to measure and quantify productivity

And of course, the topic of the work environment is always in the forefront: cubicles and open space vs. closed offices; to socialize and interact or to leave developers alone; everyone to get involved with everything or specialize; use of IM and email; working from home or going to the company; frequent meetings or not; distributed teams or everyone in one place.

My conclusion on this topic: developers to have a visible indicator that they do not want to be disturbed – either wear headphones or have a red-light on your desk

But, is social interaction and “group work” necessary for software developers?  Another lengthy discussion followed. A couple of hours later, I found myself researching this subject; and I run to the following quotation from a codinghorror blog:

… Personally I have worked in teams and alone and prefer to work alone for the following reasons:
1. Full ownership of design decisions.
2. No communication overhead with other team members.
3. Responsible for the project schedule. 
4. Can set my own high standards, and do not have to encourage others to live up to these.
5. No "babysitting" of less experienced developers (sorry, but I’ve been there and it does take time and energy).
6. Can use a project to explore a new technology, without having to justify the decision to other team members or project managers.
7. Can communicate directly with customers without having to work through any middlemen (for example project managers or dedicated analysts acting as a conduit of communication between you and the customer).
8. Don’t have to deal with other developer’s legacy code, as all of the code is mine my familiarity levels are higher.
9. Get to choose what language and database to use for new projects, assuming that the customer does not care so long as they get their web application.
10. No time required for regular team and progress meetings with managers!
I could probably come up with more, but you get the point. The only reason I miss working in a team is for the peer review of my work, but for any projects were you are able to open source the code and release it publicly, the "hive mind" (to use your term) of the open source community will review the code for you, and will quite happily and vocally point out areas where you can improve…

Boy, John is a very lonely individual…

My Take Aways

• Engineering efficiency might not be the priority of the Business Objectives – quite often, optimizing time-to-market leads to lower engineering efficiency.
• Software development productivity metrics are more qualitative vs. quantitative – a “qualitative metric” what an oxymoron!
• Agile processes might be appropriate for one type of business but not for another; this totally depends on customer expectations: if they cannot “absorb” a new release every 4 weeks, doing 2-4 week sprints does not make sense. For certain type of products or businesses, traditional approaches (including waterfall) might be more appropriate.
• Software Quality is a relative term: if the impact of making a mistake is low, qualification and stability can be compromised in favor of the time-to-release; and the reverse: if a software error can cause a major customer problem, you better qualify the product well.

Thoughts?