Software Development and the Wisdom of Many Hats

How do you make Good Software? Well, good software is defined by many factors.

  1. Does it meet the needs of the customer?
  2. Does it have an elegant design?
  3. Is it robustly coded?
  4. Is it secure?
  5. Is it free (or nearly free) of bugs?

If your software hits all five of these targets, I’d say it’s Good Software. So, how do you accomplish this? Well, let’s go through that list again, this time listing who would be in charge of each factor:

  1. Marketing (or Account management)
  2. Designer
  3. Developer
  4. MIS/Security Engineer
  5. Quality Assurance

Anyone who’s been around the block in the software development world has probably witnessed strife between any given pair of these principals. It’s kind of a fun thought exercise to picture the conflicts. I won’t list them all.So, how do you avoid these conflicts? Well, my advice is – you don’t want to! And you certainly don’t want to try avoiding them by having people play multiple roles. There’s a common saying that software QA’ed by engineers is not QA’ed at all. The same can be said about any pair of activities in this list. That’s not to say that an engineer can’t have design skills, or that a marketing person can’t know a thing or two about security. The point is that one should embrace the creative tension between all of these groups because, as James Surowiecki describes in The Wisdom of Crowds, a large enough group of people each with a differing perspective on a complex problem will invariably come up with a better solution than a single expert ever could.By having team members wear too many hats, each will inevitably make tradeoffs in his or her head before giving the larger group an opportunity to explore the possibilities. A developer doing his own QA will decide certain features are too risky to build. A marketer also doing design will be reluctant to simplify the software’s design for fear of neglecting customers’ feature requests.The correct strategy is to hire enough people to fill each of these roles individually, have each person push their particular approach to the product as hard as they possibly can, and let the wisdom of the larger group decide where the tradeoffs (security vs. usability, marketing schedules vs. QA) need to be made. Of course, communication is key, but that’s a whole other topic entirely.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>