Agile Diversity

Diversity is widely accepted as a desirable thing, whether it be genetic diversity to safeguard the survival and evolution of the species, or cultural diversity which brings character, depth and vibrancy to the human race. While I would not claim to be an expert in either of these fields, I can still understand their importance.

Genetic diversity helps by maintaining a large number of genetic adaptations within the species to give us the tools to respond to changing environment or habitat, or to fight disease. When the diversity within the gene pool is lost then the ability to react to these challenges is reduced.

Cultural diversity is often measured by counting the number of languages which are spoken but there is much more to culture than languages alone such as race, ethnicity, nationality and religion. Although these qualities may at first seem less important at first glance than genetic diversity, they are woven into the fabric of the civilisation and society that supports us every day.

So if we generally agree that diversity is a good thing, are these differences also embraced amongst software engineers? Do we find comfort in the variety of beliefs we each hold or do we feel a need to straighten the other guy's thinking out? 

Skills and experience are analogous to genetic diversity for the software engineer as they also provide the tools required to adapt to our environment and the challenges it brings each day. A wide variety of tools is desirable to ensure the most effective one can be selected for any given scenario. Cultural diversity also manifests itself in software engineering as beliefs, attitudes and methodologies and although generally more subtle, can be equally important.

All too often I see diversity suppressed and rejected in software teams when it should be embraced and encouraged. Some engineers will mock others for using the "wrong" design patterns or for abandoning test driven development when timescales are tight. Some engineers will question the commercial acumen of their colleagues for dismissing deadlines or costs. Is the software good enough? Is it maintainable? Will the customer tolerate another delay?

Identical software engineers would make identical mistakes and would have identical strengths. Isn't it better that they make different mistakes and have different strengths? As software engineers we frown upon duplication in our code and yet we try to make our colleagues clones of ourselves. While we might put together a team based on hard skills such as language, framework or domain knowledge, we rarely target the softer skills such as communication, attention to detail or methodology experience.

The truth is that we need diversity in software engineering just as we need it to sustain life. We need engineers who will get things done no matter what the resulting code looks like. We need engineers who can't sleep until "working" code is replaced by maintainable and well designed code. We need builders and we need craftsmen. We need people who understand the commercial pressures on a project and we need people who couldn't care less about profit and are simply in pursuit of perfection.

Next time you find yourself sitting in a room full of engineers from a variety of backgrounds, with a variety of experience, attitudes and skills, disagreeing on some finer point of software engineering, ask yourself if it would really be better if they were all exactly like you and in complete agreement or if the diversity around you can be leveraged to produce something better than the sum of the parts. 
Update: Interesting post on LinkedIn on this subject today.