Monday, April 21, 2003

The Middle 70%

 Steve Loughran has a great quote on Sam Ruby's blog, in a thread about whether or not SOAP sucks:

You can see the latter on the axis user mail list, where users complain that they are getting a 'connection refused' error, AxisFault 'HttpResponse:404' or 'ClassNotFoundException'and can somebody please help them. These people should not be helped. There is an informal mountaineering rule that you never help incompetents up a mountain to killed higher up, only down, to get out alive. Wannabe SOAP developers should be told to work through Bruce's TIJ book, TCP Illustrated, RFC2516, Hunter's Servlets, Box and Skonnard on XML and then maybe write a first web service.

First of all, I love the analogy. But I have to admit I go back and forth on this one a lot. As a trainer, I run into a lot of developers who probably shouldn't be writing software. At a guess, I'd say it's about 25% of them. They'll never get it. The worst of them actually think they're good. Around 5% are really quite smart - these people will create software worth using.

But that leaves 70%: what do we do with them? It's a real conundrum: systems are getitng larger, more complex, and therefore harder to do right, regardless of what vendors want you to believe. You can't do SOAP right without understanding XML, and surveys of classes find that very few developers claim to understand even XML namespaces. Security? Forget it - few can tell you the difference between signing and encryption.

There are several possibilities:

  • Yell "screw it!" and gather a team of only the smartest people to build stuff. Obviously, not everyone can do this.

  • Give up. Go into hotel and restaurant management.

  • Come up with some new way of doing things that enables the middle 70% to Do Things Right. I know I'm not smart enough to pull this one off.

  • Go with the old saying, "Educate the able, console the rest".

I think I'm somewhere in the neighborhood of the last one. As a consultant, I try argue strongly for what I feel is the right approach right up to the point where it's obvious that no one is going to change their mind. At that point, I just implement what the client has asked for, hoping that I've eroded their assumptions a little and maybe incrementally improved the product.


  1. Every industry has a middle 70%. What do they do w/ them?

  2. What a fantastic question!

  3. Im in the neighborhood of possibility #3 (Come up with some...) The distribution of talent and competence is likely to stay constant into the future. If we want to be able to build and maintain complex systems we have to find ways to enable the ordinary we have to do that. At my current company structured analysis/development/qa procedures are used to enforce a minimum "quality floor" to the code that is produced - a level of quality which it is difficult to fall beneath. This however is not the answer in my opinion for several reasons. On principal, I dont believe the minimum is acceptable. I also see procedures being used by managers and developers to avoid taking action and responsibility. The procedural solution works by making the all valleys not to deep and cutting off all of the mountain tops.