When to dismiss programmer guilt
Posted by Michael Lovitt Wed, 29 Mar 2006 20:51:00 GMT
37 Signals recently released their Basecamp API, which provides a handy way for developers to create applications that talk to Basecamp. They built their web services using simple XML over HTTP, which I found interesting, mainly because we did the same thing on a project last year. On that project, even though we had determined that XML over HTTP was the best approach, at the time I felt a little guilty about the decision.
Why did I feel guilty? Why does a programmer ever feel guilty? Generally, programmers feel guilty when they’re not building something in the best possible way—not using the right tools for the job, not adhering to good programming practices, not writing code that is general and elegant.
Usually this kind of guilt is a good thing. It results from an attention to detail and an aesthetic sensibility. It heads off laziness and sloppiness.
So was my guilt misplaced? For these web services, I felt like I ought to be using SOAP and WSDL, the standard technologies for the job. Any instructional article on how to create web services would have concurred. The absence of these technologies in my application seemed to strongly indicate a hack.
But the fact was, the SOAP implementation in the technologies we were using was underdeveloped. It worked well 95% of the time, but in some cases it simply could not accommodate the kinds of web services that we needed to provide (specifically, services that provide nested arrays of certain complex object types). It just didn’t work for us.
Further, in our research on the subject, we found that incompatibility issues inevitably occur when SOAP/WSDL services in one technology were consumed by clients from another—like when a .NET client tries to invoke a Java web service. These issues generally crop up late in a project, after a lot of code has been written that depends on a black box SOAP/WSDL implementation. At that point, spectacular hacks must be employed to work around the incompatibilities. This approach seemed less and less appealing.
So simple XML over HTTP was a sensible, pragmatic solution. It supported our immediate needs, and would likely support any future needs. Any client could use the services, since any client can be made to parse XML. Moreover, by now, most programming languages have XML parsing libraries that would make using these services trivial. In short, XML over HTTP, although neither the standard nor the obvious solution, just worked, and worked well. There was no reason to feel guilty.
Then why did I? In this case, I think my guilt was the result of a misfiring reflex, a gut reaction to something that seemed wrong. Such reactions are the root of hypercorrections—for example, when we use the phrase “You and I” habitually, even when it’s wrong. At some point in English class, we learn that the sentence “You and me are going to the store” is incorrect, which leads to the word “me” triggering a red flag in our brains, which leads to an aversion to using “me” at all, even when “me” is actually appropriate, as in: “Joe gave the book to you and me.”
Rolling my own web service protocol, instead of using a standard approach, threw up a red flag. My brain detected strong indicators of a hack and reacted accordingly—but in this case, mistakenly. Sometimes an idea has many characteristics of a bad idea, without actually being bad.
