Out of last week's (excellent) RETS conference came the ultimate software question:

Do we rewrite RETS in a new incarnation, or refactor RETS 1.7 to eliminate the (numerous) performance and implementation problems?

Along these lines, Chris McKeever forwarded a classic Joel Spolsky post titled "Things You Should Never Do, Part I" (oddly, there is no Part II) on the dubious merit of scrapping & rewriting any piece of software.

I mostly agree with Joel; however, I have some apprehension because there are examples of (very) successful rewrites: MacOS to Jaguar, Adobe Photoshop, HTML, eBay, MySpace, and so on ... and one purpose in those rewrites resonates with RETS 2.0: a fundamental change in the underlying architecture.

RETS 1.0 specified everything -- implementation, transport, protocol, and data standards. About all it didn't do was include a specialized implementation of TCP.

RETS 2.0 is light fare by comparison -- a data and interface description standard. Most of the plumbing (transport & protocol) that made 1.0 complicated is supplanted by existing Web Services standards: HTTP, XML, authentication, and the atomic transaction have all been written by other, smarter (or at least more directly focused) people.

Should RETS 1.x be refactored to current standards?

Pros:

• RETS 1.5 & 1.7 are implemented in a majority of the software in the market.
• RETS 1.7 can be "wrapped" in Web Services.
• Significant work has been done by the CRT (and a few third party ISVs) to make RETS more accessible (libRETS, ezRETS, Variman, Viele, and so on).

Cons:

• RETS 1.5 & 1.7 are implemented haphazardly, and almost each implementation has some sort of workaround to disambiguate part of the specification.
• It is very, very fat with overhead (even if not sent over the transport because of the compact format, it still requires implementation & maintenance).
• No supporting documentation is provided beyond the single, 130-page specification which is rife with wishy-washy "MAY"s.
• Antiquated (to say the least) DMQL.
• People have been trying to "fix" RETS since its inception, and it just ain't happenin'.  Why kid ourselves with the idea that we can resolve a decade's worth of issues inside of a year?

Yes, RETS 1.5 & 1.7 can be patched to resolve some of the ambiguity problems (at least the low-hanging fruit).  However, how much effort (and vendor buy-in) will go into maintaining three parallel versions of RETS?  Why would a vendor who is stuck on 1.5 choose to implement 1.51 instead of 1.7?  Why are we giving them an "out" to not update their code?

Yes, RETS 1.7 could be wrapped into a Web Services framework and appear modern at the surface, but that draws all the worst "lipstick on a pig" analogies you've ever heard (or, if you haven't, "you can put lipstick on a pig, but it's still a pig").  How many hoops will we have to jump through to get it working correctly?  Remember that such a solution creates at least three layers of obfuscation to the actual data: three layers of code, potentially from three different vendors, all with bugs or, worse yet, special fixes to the other vendors' bugs (increasing fragility).

Call me old school, but I want one, monolithic, no apologies, no exceptions standard.  Make the service contract very explicit, and do not grant compliance certification to anyone who fails for any reason.  Write some white papers, get someone to write a book, and have a half-dozen professional data architects go over the spec to make sure we're doing the right thing.

We need to make people (programmers and consumers) want to use it and ask for it by name.