MattL.com

Today, it was formally(?) decided that RETS 1.7[.1] is about the best that can be achieved before the NAR's June 2009 deadline.  For the sake of edification, I'm including it here:

The integrity of data is a foundation to the orderly Real Estate market. The Real Estate Transaction Standards (RETS) provides a vendor neutral, secure approach to exchanging listing information between the broker and the MLS. In order to ensure that the goal of maintaining an orderly marketplace is maintained, and to further establish REALTOR® information as the trusted data source, MLS organizations owned and operated by associations of REALTOR® will comply with the RETS standards by June 2009, and keep current with the standard's new versions by implementing new releases of RETS within one year from ratification.

Now I'm going to do the posh thing and quote myself:

There is absolutely no chance RETS 2.0 will be done in fourteen months.

-- Matt Lavallee, RETS Assembly Meeting, Chicago, IL, August 9th, 2007

All I got then was hand-waving and chuckles...  Today, I may as well call myself The Nostradamus of RETS (although no one else will).

The ".1" incremental build is to correct some minor errata in the documentation of the specification.  This is truly pathetic:  RETS 2.0 was started in 2004.  How can anything be this slow?

For the sake of argument, let's look at the timelines of some other widely-known specs:

1. HTML
1. Version 1: 1993.
2. Version 2: 1995.
3. Version 3.2: 1997.
4. Version 4.0: 1999.  Note: Considered "good enough" by most of universe.
5. XHTML 1.0: 2002.
6. [X]HTML 5.0: 2008.
2. SQL:
1. ANSI v1: 1986.
2. FIPS 127-1: 1989.
3. ANSI SQL2: 1992.
4. ISO SQL3: 1996.
5. SQL1999: 1999.
6. SQL2003: 2003.
7. SQL2006: 2006.
3. Wi-Fi (IEEE 802.11)
1. 802.11: 1997.
2. 802.11a: 1999.
3. 802.11b: 1999.
4. 802.11g: 2003.
5. 802.16 (WiMAX): 2005.

I understand the issues of timeline management and pragmatism, but come on... this isn't rocket surgery.

Here's how I understand our current timeline:

• RETS 1.7.1 - Expected standards vote December 2008, adoption by June 2009
• RETS 1.8 - Expected standards vote August 2009 (?)
• RETS 1.9 - Expected standards vote... December 2010?
• RETS 2.0 - Prediction: 2015+

This makes no sense.

Nearly every developer is a diamond in the rough in some way; rarely is a new employee a perfect fit for the job, even when their resume says so.  I think this happens for a few reasons:

1. Resumes (and sometimes even blaring overconfidence) exaggerate most candidates' skills.  Most often, it's because they knew how to pull every handle and turn every knob at their last job, so they must be an expert... when, in fact, they were just experts at their last job.
2. Your job opening is almost never the same as their last job.  Unless you're hiring laterally from another department or absconding an employee from a direct competitor (who has the same platform and build process as you), your job will have unique requirements and being productive in that job will require implicit knowledge of how your company or department operates.
3. "Perfect" is a subjective mix of wisdom, efficiency, insight, overall productivity, communication, and socialization.  It's impossible to be Perfect on Day One, if not Year One.

Recognizing this, I try to keep an open mind when hiring new staff (which I've been doing tirelessly for the past two months).  There are really only a few traits I key-in on:

1. Appropriate level of knowledge for the platform.  I've been hiring for a .NET developer with a modest SQL background.  I don't particularly care if their experience is in C# or VB[.NET], I just care that they've had solid experience with the framework itself, which is an immense geography of 2500+ classes and tens of thousands of functions, so in particular the parts that we use most (data and IO).  I check mostly for awareness and a keen sense of what's-what (like the difference between Inherits and Implements).
2. Good programming.  Beyond linecoding, being a good programmer means that you know how to back up, consider the bigger picture, and write what needs to be written (and nothing more).  God bless those uber-efficient linecoders who can churn spec into code for months on end, but you need three architects to keep them on track (which we don't have).  This one is harder to sniff out, but not impossible.
3. Raison d'être.  Some developers only write software to cash a paycheck. Ironically, most of them don't seem to realize that they're being outmoded by newer, faster, smarter developers who are eager for their paycheck.  Continuous improvement isn't just a corporate thing, it's a career thing.  I take it as a sign that anyone who hasn't flexed themselves in the past 3 years thinks they know all they need to know, and I don't hire those people.

All of this preamble was a build-up for my soapbox on Professional Development™.  It is far too easy for developers to stagnate, and they usually don't know they're a dinosaur until they're being "let go" in favor of newer/younger blood that has three times the depth in current technology and can't find a job.  Likewise, I'm there are many companies looking to expand their Lotus Notes & CORBA integration project from 1997 and want to see more "web 2.0" in it.  The reality is that those companies are mired in the 10-year-old mentality because they didn't help (or push) their developers into staying current.

At MLSPIN, I've been instituting the best policies I've ever learned working for various software companies, large and small, or heard of through online sources:

1. Conducive environment.  This is the hardest, since it takes a lot of money and there's only so much you can do with the facility.  My developers work in a bullpen (less than ideal), but have plenty of space and new ergonomic chairs.
2. Productive equipment.  Each developer has a real HP workstation, with a quad-Xeon processor (room for a second), 4GB of RAM, 15K rpm SAS drives in RAID 5, and an ATi FireGL video card (because they're better at 2D than nVidia).  Each also has two 20" flat-panel monitors and their choice of keyboard & mouse.  We run Visual Studio 2008, and each developer has a copy of Photoshop Elements and SnagIt.  I also have a 5-seat license of MSDN, so we can tinker when we're planning new stuff.
3. Progressive training.  In addition to the modern cachet of books, we provide $2500 in tuition/certification reimbursement, pay the certification exam fee for any passing score, and offer merit bonuses for accomplishing their certification goals.  I'm also committed to having two "superstar" training weeks each year.

The first training session this year was held in January and featured the inimitable Bill Vaughn.  Aside from being one of the founding fathers of ODBC and grandfather to ADO, Bill has the most comprehensive knowledge on programming against databases in Microsoft technology that I've ever even heard of.  Buy his books, they make you smarter.  In a week's time, Bill was able to convey as many nuances to the technology as I've learned in a decade of hands-on work, and I still learned new tricks.  He's very personable, doesn't believe in stupid questions, and knows how to mentor.  We liked him so much, we've now got him on retainer.

I still haven't decided who to have out for the August-ish session, so if you have any suggestions, drop me a line.

So, that's my pitch.  If you are a professional developer, do whatever you need to to stay current, and if your company doesn't support that, leave.  If you're a company who doesn't believe in training your resources, send me your developers' resumes.

-Matt

I realize I must be thick in the head, but...

1. Thousands of developers across the globe "contribute" to MySQL to make it a reasonable RDBMS.
2. MySQL AB maintains a shell company of 350 people to sell and license this freely-derived product to corporations for thousands of dollars.
3. Sun acquires MySQL for ONE BILLION DOLLARS.  Contributing developers get... nothing.  A bunch of already rich people get more rich.

I must be totally off my rocker, because I see this as another sign of how "free" software hurts the developer community.  How can anyone stand by the Writers Guild while they fight for residual income (after they've already been paid once) and yet, in the same breath, say that not paying developers for their work makes sense.

I just don't get it.

Closing on 2007 means closing a major turning point in my life.  In one short year, I've had another son, built a house, left one great job for another, gotten remarried, made new friendships, lost old ones, deepened my involvement with RETS, and set about building the best MLS in the country.  It truly has been a pivotal time in my personal history.

RETS, RETS, RETS

A good portion of my brainpower this past year has been focused on improving RETS, the Real Estate Transaction Standard(s).  It's simply fantastic to be involved in such a high-profile standard with so many great Real Estate technology professionals.  My thanks particularly go to the rest of the "core" Schema team: Paul Stusiak, Gina Accawi, Peter Spicer, Michael Wurzer, Gregg Petch, Eric Petersen, Sergio Del Rio, Chris McKeever, Joshua Vosper, and Jaison Freed.

It's also easy to overlook the wizard behind the curtain, but a great debt is due to Mark Lesswing.  In a single year, he's transformed a motley crew of interested participants into a gen-u-ine organization.  Beyond this, his grasp of the technology proposition to Real Estate is virtually unparalleled.  Regardless of his other accomplishments, it's hard not to consider him one of the great RE technology luminaries of this decade.

On a related note, Michael Wurzer (RESO Chairman and President & CEO of FBS) posted an open letter to the mass listing aggregators of the world.  Proving the value of the Web 2.0 world, enough responded that some sort of open discussion will take place at Inman's Connect NYC.  Mike's certainly shaping up to be a luminary himself.

<technical>
My consequential involvement with RETS is the Query language, dubbed RQLX (although it's a bit of a grandfathered name that lacks significant meaning).  Through numerous posts between myself and Sergio Del Rio on the RETS-DEV mailing list, I countered the necessity of a number of staid data archetypes (dictionaries and vocabulary) in RETS 2 that existed largely to resolve the problem of unique particle attribution in RETS 1.x.  The reality is that the RETS 2 Schema have evolved into a fairly monolithic namespace, which makes UPA a distinct reality without needing alternate representations of the data set.  My only wish is that I could learn ANTLR well enough to (quickly) write a functioning, provable grammar... but I'm getting there.
</technical>

How to Build a Great MLS in 10 Easy Steps

As if.  As much as my background may have prepared me for this effort, building the new, ground-up version a large-scale MLS is no small feat.  Amidst the travails of the past two months, moving 1200 miles and traveling nearly 20000 more for various professional and family events, I've also had to re-align and rebuild a development team for MLSPIN's next great release in 2008.  I have two open development positions if anyone's interested (or if you know someone) with ASP.NET and heavy MSSQL skills.

Thanks to Microsoft's [un]timely releases of VS.NET 2008 and, more significantly, LINQ, I also have about two weeks to decide whether we write against the (proven) ASP.NET 2.0 platform or the far more streamlined ASP.NET 3.5 platform.  Any insight or feedback is also welcome.

On the corporate side, I can't understate enough how valuable it is to have faith from your leadership: with Kathy Condon (my CEO) and Tony Mastroianni (my CTO) providing such solid backing, I'm confident we're going to release a monumental MLS system and make significant strides in raising the MLS bar.  To that end, I also owe a bit of thanks to Michael Wurzer (FlexMLS) and Colby Ackerfield (RealGo), both of whose candor and guidance is deeply appreciated.

Family Notes

Lucas is nearing his first birthday, growing into a character of his own by the day:  He's such a great baby.  Ben just started Montessori school and continues to amaze us with his intelligence and compassion.  Kerry is continuing to acclimate to the geography (New England's a far cry from the Southwest) and a new station in life as a stay-at-home mom.  I probably don't tell her enough, but she's held up wonderfully.  I couldn't ask for better kids or family, period.  Almost all of our Illinois houses are sold and that will be a great relief as we look to buy a house next Spring.  It's all coming together, finally!

As most of you know, I've been at the core of an ASP -- PMPVOWs.com -- for the past five years of my life. Originally a marketing ploy and one-time contract, the service quickly blossomed into a "real" business and a full-time career. Over this time, my participation in this great Real Estate web community has flourished to the extent that I'm now chairing a committee as part of the National standard (RQLX).

All this time, my employer's greatest fear was that I'd leave for greener pastures -- a notion I'd mocked on several occasions because I loved who I worked for and what I was doing. However, the one genuine "threat" that I'd always given credit was the opportunity to return "home" to New England: Let's face it, no matter where you've been transplanted, there's no place like home.

Well, a little over a month ago, random chance became destiny: through a series of events that can only be described as Shakespearean in dramatic and comedic value I've accepted a position with MLSPIN, the largest MLS in New England, as Software Development Manager. In early November, my family and I will make the trek back to my seemingly long-lost homeland. I've entrusted my baby in the capable hands of Magenic, an outside development firm with whom I've had some previous experience and that has solid history taking over in-house apps.

Beset by poison monkeys...
So, last Wednesday night, amidst the comings and goings of consultants and trying to dump over four years of hands-on experience with tens of thousands of lines of code, I fell ill. At 1am, I woke with fever ripping through my body and a headache that trumped some of the best hangovers I've ever earned. I took a couple of Tylenol and forced myself back to bed. By 5am, feeling worse, I took a couple of Advil and, again, forced myself back to bed, knowing that work wouldn't be in my future that day. By 9am, I was calling Kerry to bring me to the ER.

The good folks at Edward Hospital wasted no time... within two minutes of interviewing with an admittance nurse, I was rushed by wheelchair to an emergency room. The conclusion was reached fairly quickly: Spinal meningitis. The rest of the day is a blur -- I remember a CT scan, lots of drugs, a needle in my spine, lots more drugs, and being "isolated" to the point that everyone had to wear masks.

Fortunately (?), it turned out that I had the simple form of "viral" meningitis, which can be just about any virus that decides to attack the meninges (protective lining of the central nervous system).

I was taken off isolation on Friday, went down for an MRI to be sure that my brain wasn't still being attacked (particularly by the Herpes variant, which can leave you stupid), and became really good friends with Dilaudid, a remarkably strong pain killer that takes all of about 60 seconds to kick in. I was also infused with a half-dozen of the strongest antibiotics and antiviral agents available to man, and by Sunday was well-enough to be released.

A word of advice: no matter how good you think you feel, take them up on all of the take-home drugs they offer. I was offered vicodin and zofran for pain and nausea, and turned them both down ("I'm feeling much better!")... only to spend the next 22 hours in bed because every twinge made me want to hurl.

So, I'm alive. Beaten down, but alive. Thank goodness for medicine, all the good people who sent sympathy my way, and a strong family support network who made my untimely hiatus less painful to those I love. Also a big thanks to Barton Pitts, President of my current company, who was about as concerned as my own mother and more understanding than any lame duck's boss should be.

Michael Wurzer posted (over at the FBS Blog) his commentary on the ever-roiling hype around map-based searching in MLSes and for real estate consumers, borne out of Real Tech LLC's implementation of polygon-based mapping for John L Scott.

Whenever I ask our client base what features they'd like to see added to our service, map-based searching (MBS, for short) inevitably takes one of the top three positions.  However, when pushed with the 5 Whys, virtually no one can get past "because xyz does it!"

I have closely followed the various online mapping options since they became financially accessible and widely accepted (roughly 3 years ago). However, based on numerous seminars and conversations with end customers -- as well as top people at the mapping vendors -- the reality is that mapping hasn't either A) matured sufficiently for, or, B) proven its value in, our market.

As I've pointed out on in several RE forums, I'm skeptical at best of the merit of broad, location-based searching. I personally believe the value is in context-based geography, such as "maximum distance to x school, y office building, and z office building". The problem is then the processing power (and licensed software) required to provide those results in a sub-second period... not an easy trick when you have to scale to thousands of searches per hour.

At last year's Connect SF, I had the opportunity to discuss at length the issues surrounding MBS with Microsoft's Live (nee Virtual Earth) Maps team.  Out of those conversations, Microsoft added off-map drive-time calculation for points (which Google also implemented mere days later).  Unfortunately, the reality of having to load several hundred candidate points and perform the calculations against their servers still proved too latent an exercise to be useful.

The average real estate consumer -- the should-be target of these features -- simply does not rank the featureset nearly as relevant as price, bed/bath count, and square footage... especially when beginning their search, which is how most of these tools approach the visitor.  In fact, I think most consumers will sacrifice location in return for a house that otherwise meets every need.

This year, we will add interactive mapping to the Favorites feature of our service, only because it will include multi-point route optimization (for planning drive-by tours and showings).  To me, this is the extent that the technology has provided value to the consumer.

I would much rather let the big corporate vendors spend millions figuring out what works, then implement those features for a few thousand dollars in a quarter of the time.

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.

In this post at the Mini-Microsoft blog, Mini makes the argument that there are too few "qualified" applicants for the Microsoft programmer ranks, citing that they should be educated in "C/C++, Win32, COM, ATL, XML, DHTML, AJAX, .NET, debugging, performance, Watson analysis, design patterns, security, using our best internal tools and resources and so on."  And instantly I understand why so much of VS.NET's auto-generated code is terrible, and why their Atlas library requires a developer "think like Microsoft" (answer: because no one else does).

Further:

[...] more and more candidates who can lay down the smack with Java and script can't manipulate memory and discuss deep operating system constructs just-in-time at all. I need you to be able to write a GC, not be in an unhealthy co-dependent relationship with one.

It's that sort of painfully dated thinking that maintains Google's ownership of web innovation while Microsoft struggles to be noteworthy.  A talented, creative scripter has absolutely no domain over deep memory management and should never have to think about it: That's why you have talented, deep memory guys in the first place.  What's the purpose?  Advancement?  I'd start looking for other apocalyptic signs if any of the AJAX wizards I know hint at working on some nice kernel code; I would no sooner expect a podiatrist to be studying neurosurgery.  While collectively still "programmers", many of us have highly diverged specialties sharing little in common but tools of the trade.

Don't get me wrong -- being familiar with the clockworks required to make your code work is a Good Thing™ and often leads to higher quality code, but it's no substitute for creative thinking and one can argue that the focus gained by an "unencumbered" mind is equally valuable.  As a master generalist myself, I tend to see my greatest shortcomings while overthinking problems and overarchitecting solutions -- a problem that doesn't plague those with shallow skills.

Perhaps Mini's viewpoint is a one-man reflection of the great cancer that keeps Microsoft from being great, though it's terribly ironic that it's coming from the guy so passionately trying to instigate change.

I once posited that Marketing people shouldn't run technology companies, and most examples of publicly-traded companies prove me right:

Tech people running tech companies well:

• Intel: Andy Grove, Craig Barrett, Paul Otellini.
• Apple: Steve Jobs and Steve Wozniak.
• Microsoft: Bill Gates, Paul Allen.  Ballmer is a tool.
• Samsung: Yun Jong Yong. BSEE, MBA.
• VeriSign: Stratton Sclavos. Dual BS in EE and CE.
• AMD: Hector Ruiz, PhD in quantum electronics.
• ATI: Dave Orton, BS in Mathematics from Wake Forest, MSEE from Duke.
• Creative Labs: Sim Wong Hoo, Co-Founder, Co-Inventor, EE.
• nVidia: Jen-Hsun Huang, MSEE from Stanford, former microprocessor designer at AMD.
• Google: Eric Schmidt, former Novell CEO and Sun CTO. PhD in EECS.  Co-creator of lex.  Page & Brin both hold MS in CS from Stanford and Google was their PhD thesis (still in progress).

Examples of non-tech individuals ruining tech companies:

• Symantec: John W. Thompson, former Marketing VP.
• Computer Associates: John Swainson, former Sales VP.
• McAfee: George Samenuk, former Customer Service VP.
• Novell: Jack Messman... Environmental Services CEO.  Banking CEO.  Publisher CEO.  Chemical Engineer by degree.  Sank the company almost single-handedly.
• Novell, Part 2: Ronald Hovsepian, former Sales VP.
• Dell: Kevin Rollins, MBA management consultant.
• Gateway: Ted Waitt, co-founder, marketing student.
• Gateway: J. Edward Coleman, BA in economics, MBA.
• Hewlett-Packard: Carly Fiorina, BA in medieval history (I shit you not).  Got her MBA in 1980 and was hired as a management trainee by AT&T in 1980; slogged through there and Lucent to rise to President of Consumer Products in 1996.

Exceptions:

• Adobe: Bruce Chizen, Marketing/Sales history.  Arguably logical because of their market niche (marketing people).
• Hewlett-Packard: Mark Hurd, BA in Business Administration.  Spent 25 years at NCR becoming a tech/re-org guru.

Oh, and just to cover Patricia Dunn's curriculum vitae:

• Former part-time secretary at Wells Fargo who rose through the ranks, also working as a freelance journalist.  BA in Journalism.

Today's little rant was sponsored by the dual appearances by Patty Dunn and Carly Fiorina appearing on 60 Minutes.

Patty lucked her way to the top by being a stickler for rules; ironically being ousted for breaking the rules that we crazy laymen call "laws".

Carly.  Ahh, Carly.  I honestly think that she was probably a hard worker at Lucent that was over-promoted and, sadly, became addicted to the idolatry that came with her success as a very powerful woman.  Her reign at HP was fraught with selfish acts (the yacht thing, hanging her portrait alongside Hewlett & Packard in the lobby, etc.) and generally sounding like a buffoon on financial matters.

Now she's trying to claim that she was the catalyst behind HP's current wave of success.  As a long-time HP customer, I just can't see it.  She tried to generate success for HP through pure marketing sparkle, making splashy moves that would generate lots of industry buzz, but with little respect for the business or human issues required to actually make those moves work.  Like a movie hero, Hurd's the one who came in at the final moments and saved the train from careening off its tracks.

Again, as a customer, I'm a hundredfold happier since Hurd took over: the products have direction, customer service is way up, and prices are (as they should have been all along) on-par with Dell.

Ah, the wicked mistress that is JavaScript.  It has been years since I really got into JS; sure, I've made my share inline popup dialogs, AJAXified pages here and there, but nothing really in-depth since the bad ol' days of IE 5.5 and the DOM nightmares that would wake me in a cold sweat.  I really didn't miss that aspect of JavaScript; certainly no moreso than a POW misses the war.

Well, it's a new world nowadays (old-timer talk):  The DOM is almost universal and JavaScript has grown up... way up.  Actually, JS hasn't grown up so much as the platforms (mostly) comply with the ECMA ratification from all those years ago.

Don't get me wrong -- back in the day I loved JavaScript as much as I loved my first new car.  It was like Java and C++ without all the hassle, and you could make the web do tricks at a time when it was 99% static (god, do I miss those days).  BUT, the aforementioned pain of cross-browser support meant hours and hours and hours of testing, tweaking, implementing tiny code "shims" to get stuff to work right ... it almost wasn't worth it in the end.  The original menuing system at Pergo.com (dynamic JavaScript with HTML drop-downs loaded by Vignette that was 6-language friendly) took me weeks to get working properly.  In the days before JSON, it was quite the technological feat to have all of those disparate points of navigation play nicely as a huge multi-dimensional array.  It worked something like this:

pergo_menu[0] = new Object();
pergo_menu[0].text = "Interior Design"
pergo_menu[0].url = "../b/b1_interiordesign.html"
pergo_menu[0].items = new Array();

pergo_menu[0].items[0] = new Object();
pergo_menu[0].items[0].text = "Inspiration"
pergo_menu[0].items[0].url = "../b/b2_inspiregallery.html"

pergo_menu[0].items[1] = new Object();
pergo_menu[0].items[1].text = "Q&amp;A designer"
pergo_menu[0].items[1].url = "../b/b7_talktodesigner.html"

That was all the backend guys had to do to update the nav.  Not bad, even by today's standards.

So last week I was back "home" in New Hampshire for a long weekend of R&R and some great quality time with my three younger brothers.  One friend of my brothers, Lokesh Dhakar, had long had web dreams, and I'd heard through the grapevine (brother #2) that he'd gotten a job offer from Google.

Me: "Hold the phone... Google?  Lokesh?  Google?"
Brother: "Yeah, he invented some kinda new popup thing that everyone in the world wants."
Me: "Uh, okay."  (brother is not web-savvy)

In the night of formal brotherly carousing, friends from near and far gathered at a local tavern, including Lokesh.

Me: "Hey, Lokesh, what's up?" (we've always been friendly, although I used to be the cool web guy... now the shoe's on the other foot)
Lokesh: "Hey, Matt!  Good to see you."
Me: "What's this about you inventing popups?"
Lokesh: "Well, that's not really it.  I made this thing that pops up on pages and makes it really easy for anyone to implement.  I got calls from Yahoo, Google, Microsoft, and a bunch of others.  That's how I got my current job."
Me: "Uhh, popups?"
Lokesh: "Well, it just made them easy.  Check out my website and Lightbox and you'll see."

To me, Easy Popups != Google job.  There had to be something more.

Indeed there was.

Lightbox leverages the prototype library, script.aculo.us, and a whole lotta DOMmin'.  The result is a really, really, mindlessly easy way to add a pretty "see larger image" link on a web page.

About two hours later, I was incorporating the concept into our web service's dev system.  I've long done "pop-in" dialogs with IFRAMEs and a PNG shadow, but the effect of a pseudo-modal, smooth interactive element is a thousand times better.

So now I've been JavaScripting for two straight days, loving and hating it all over again.  The remaining burning question:

WHY ISN'T THERE A REAL JAVASCRIPT EDITOR YET?

Seriously.  The language is there, the platforms are there, but for the love of king and country I still can't debug it without silly elements named "tracediv" and a whole bunch of nodeValue calls.

Debugging in IE is still a joke, even with the developer toolbar (please stop overriding CTRL+R, thank you).  That being said, I still haven't loaded the Venkman JavaScript Debugger...  That's for tomorrow.