More Thoughts on Techies and Modelers

You may recall that Ted recently talked about the distinction between techies and modelers. I then questioned his "technieness" - by his reaction you'd have thought I questioned his parentage and sexuality both. :)

Regardless, Ted now has this to say on the same subject:

The more I come to know people at Microsoft, the more I'm realizing that most of the technical folk at Microsoft are techies--people who keep a careful eye on the underlying details and implementation. This attitude of "performance first" or "scalability first" definitely plays out well in certain scenarios, but can lead to some interesting and perhaps undesireable consequences.

While I'm all for maintainability, in this debate I often come back to a statement that Tim Ewald once made: "Your users will never come to you and maintain that your system isn't object-oriented enough." They will, of course, tell you when it's slow.

I'm not saying that Ted is claiming that OO == maintainable. But I think there's a general perception out there that this is the case. Our notions of "well designed" or "elegant" code have come to encompass the bill of goods that the OO purists sold us in the 1990s. But that's an aesthetic metric, and therefore a subjective one. I ask the question: is there something about OO that is inherently more maintaintable than a well-designed procedural system? I'm not sure there is. And when you combine the performance issues with objects in distributed systems with the fact that everyone gets procedural programming but OO takes like three years to penetrate your brain properly, the picture starts to get even more muddy.

I'm not saying that objects are bad. I'm just saying, they don't equal goodness. And linear programming doesn't equal badness. I'm sure Ted would agree.

Gadgetry

This looks cool and I want one.

The Birthday Problem Calculator

A friend of mine wrote me up on IM the other day, asking how to use a hash algorithm to generate short, unique identifiers out of a longer piece of information. I suggested that she ditch the hash idea and just generate random numbers. It's pretty much the same thing, after all, since she was going to be storing the lookup information in a database anyway.

Her first (and fairly natural) reaction was "What about collisions?" After thinking about it for a second, she remembered that a hash isn't guaranteed to be unique - how can you come up with a one-to-one mapping from all possible four-page documents to a single 32-bit number? - so she had to have the code in place to check for duplicates anyway. But it did raise the question, "How likely is a collision to occur?"

In this article, I explain how we answered that question.

Richard Blewett Joins the Fold

My friend and fellow DevelopMentor instructor Richard Blewett now has a blog. Here's the URL. Here's the RSS.

I've had dozens of conversations with Rich - including this one - but we've never actually met face-to-face, since he lives in the UK and we've never happened to teach together.

Subscribed!

Another Sort of SOAP

Here's what the really hard-core web service zealots play when they're not working: SOAP.

XML Is a Virus

In the beginning, there was the .INI file.  Then, Microsoft created the Registry, and only an idiot would ever store configuration in some text file just lying around on disk.  Then, Microsoft brought us .NET, and .NET brought us .config.  We're back to .INI files, they're just XML .INI files.  And, you can use an XPathNavigator to search the registry.  How weird is that?

Clever post.

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.