SEMAT and diversity
Recently I saw an article lauding the diversity of the participant group for the Zurich workshop on SEMAT. That bothered me for two reasons.
Recently I saw an article lauding the diversity of the participant group for the Zurich workshop on SEMAT. That bothered me for two reasons.
One, the post seemed to assume that the gathered group was sufficiently diverse in viewpoint to solve (SEMAT's current view of) the software problem.
Two, the group didn't seem that diverse to me in many important regards other than methodological viewpoint.
This creates risks which are, ironically, far from uncommon to software development. Assuming that you know your customers well enough (or that you are them), and know what they need, can be a recipe for building a technically sound product that doesn't "sell" and won't be used. I don't want to see that happen to SEMAT. Here's why I'm concerned that it might.
In brief: the software problem isn't just their problem - it belongs to all of us.
1. Non-diversity in viewpoint
My impression from reading the SEMAT signatory list is that the Zurich workshop participation likely was not as diverse or as representative of the software world as they thought it was. To me the (self-selected) SEMAT crowd seems quite US/Europe-centric, and mostly (>80%) academics, methodologists, and consultants, as opposed to active software practitioners.
That's not optimal, but not necessarily bad - not unless the participants fail to avoid the mistake of thinking that they are (or represent) the ultimate stakeholders or customers of SEMAT.
A highly diverse and representative group of real-world practitioners should be the most important customer/stakeholder class. In my view, they are at least 80% important, and the academics, methodologists, etc. should all comprise no more than 20%.
I have great respect for the many SEMAT participants whose work I know. I see no issue with the people who do the 'heavy lifting' on SEMAT coming from the expert few percent among the 20%, as long as they realize that they are not representative of the other >80% who are the customers and stakeholders of SEMAT, and they take appropriate steps to elicit and address the customers' needs.
2. Diversity among SEMAT's customers >> diversity among SEMAT participants
Even diversity in methodology isn't enough. In defining and building the customer base from whom they elicit requirements, I hope SEMAT will actively strive to be broadly inclusive in addressing their call for action. For instance, here are some of the diversity dimensions I think are important for the customer base for SEMAT ... how well did the Zurich workshop participant group represent them?
Viewpoint: How many people who deliver software products (vs tools or consulting services) participated? (practitioners vs gurus - the main gap)
Domain: How well did the participants represent the great breadth and variety of industrial software product domains?
Gender: How many women were there? (I see just one female signatory on the SEMAT home page, and none in the pictures from the workshop)
Location/Culture (not necessarily the same, but): How many people participated who are currently doing development in India, China, Korea, Japan, Malaysia, Russia, Argentina, Brazil, Mexico? (NB: kudos to the SEMAT troika for recognizing that access to the blog from China might be problematic, and taking steps to guide readers there)
Education: How many participants did NOT have computer science or software engineering academic training?
Experience: How many people who have started developing software professionally in only the past 1-5 years participated?
Roles on Projects: Developing good software takes 'many hats'. Are the perspectives and needs of all of those hats represented? For instance, how many participants were involved whose primary job is testing software?
Do these dimensions of participant characteristics matter? In theory, perhaps they don't -but one of the many differences between theory and practice is that, in practice, these characteristics do matter. And practice, not a beautiful theory, is what matters in whether SEMAT is ultimately successful.
It is heartening that one of the key workshop outcomes (summarized on the SEMAT blog) was an awareness that attention needed to be paid to defining the requirements for SEMAT. But will their first steps include broadening their vision - not just of the theory and methodology space, but of the global and diverse 'market' of stakeholders whose needs they propose to (perhaps indirectly) meet?
Anyone who has developed software for customers or a market knows it can be difficult to convince users who are crazy busy to make the time to engage in this discovery process. This same phenomenon, noted as one of the key challenges in software development in a thoughtful posting about SEMAT, is also a challenge for SEMAT.
This won't likely be easy to do, but if the SEMAT team tries and succeeds in this essential first step of requirements elicitation, I will be much encouraged on their prospects for succeeding and making a real difference in software practice. As one participant noted regarding methodological diversity in his comment on the InfoQ posting, "Hopefully the diversity will grow at a sustainable pace, something I believe should be a goal but will require patience." I echo that sentiment regarding the global customer base of SEMAT.