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.