RIA == Platform Play

The shortness of the collective memory of the development world depresses me sometimes. Joel Spolsky has a great blog post from 2004 entitled How Microsoft Lost the API War. In it, he describes the real Microsoft crown jewel that lead to their domination of the personal computer: the Win32 API. If you were writing software in the mid-90's, you were writing it to the Win32 API. You might be using Visual BASIC, Delphi, PowerBuilder, Visual Objects (all 2 of it's users), FoxPro, dBASE for Windows (all 4 of it's users), etc. But you were writing desktop applications that ran on Windows. Then, Netscape came along and showed everyone that you could write software to open standards. Even though Microsoft eventually trampled Netscape, the damage was done: now you could write software that ran in browsers. Of course, Java had the whole "write once, run anywhere" mantra going, but building desktop applications in Java sucked then and it sucks now. Only a few companies have ever done it well (like JetBrains). Netscape's enduring legacy was that writing to standards (like HTML, CSS, eventually DHTML and JavaScript) was, while painful, possible. You can create rich applications where no one knows or cares in which language it's written.

Fast forward to today's development world. We're used to the pain required to write good web applications. We've got Ajax frameworks to smooth over the painful parts of JavaScript, people actually understand CSS, and you can build compelling applications on the web. Not an office suite, mind you, but pretty functional applications.

Which brings us around to the current hotness, Rich Internet Applications (RIA). Ever wonder why Adobe and Microsoft are slugging it out for that space? And Sun is running along behind with JavaFX saying "Wait, we want to fight too!". It's the new platform play. We've dealt with the pain of writing good looking web applications so long that when someone comes along and shows pretty pixels, we swoon. Yes, you can create beautiful applications using Silverlight and Flex. And Sun showed some awesome demos of JavaFX at JavaOne. But, if you write an application in one of those tools, you've bought a platform. You are no longer in a standards space. You can't take a Silverlight application and port it to Flex without a rewrite. Same goes with JavaFX. Whoever wins the RIA war has the new dominant web platform, just like Win32 back in the day. Sounds like a good reason for big companies to pour resources into the effort.

Of course, as my friend Mike Nygard pointed out during several expert panels, you pretty much buy into a platform play every time you start writing software. Yes, JEE is a standard across many application servers, but how many people are really careful to isolate the seductive goodies that come with your application server from the real JEE stuff? My guess is not many. So, you've kind of implicitly bought into a platform anyway. That's doubly true for .NET: yes, Mono exists, but more of a proof of concept than anything else.

Maybe this is OK. But I remember the reason to avoid single vendor platforms. One of the compelling reasons to move to Java when the JEE specs came out was the possibility of moving to another vendor, even with some strenuous effort. I can't tell you have many consulting clients I encountered in the mid-90's who had bought into a particular platform (say, Microsoft Transaction Server or ColdFusion) and were very productive with it...until they hit a real bug in the platform itself. I consulted at one company who had an 18 month project written to a proprietary platform when they encountered a show-stopping bug. They contacted the vendor who said "Yeah, that's a known bug. We're going to get a fix out for that in the next release, which should be in about 12 months". Even though it took them a long time, they scrapped what they written and started over, in Java. And you can bet they were careful about isolating the application server stuff from the specification.

Building to a single platform isn't necessarily a bad thing, as long as you go in with your eyes open. It's a trade-off: perhaps the pretty dancing pixels in Silverlight are worth the chance that you'll find something it doesn't support and end up with an application that doesn't quite do what your users want. But, beware of Dietlzer's Law: users want what they want, and are grumpy if you tell them "no". And, if you go with one of the RIA platforms, get ready to marginalize everyone without a PC. Some of these platforms have some support on mobile devices (and surely more to com, in a massive wave), but it's not going to be as good as plain old HTML for a long time.

If you are going to choose an RIA platform, please use it appropriately. Don't build forms in it: HTML is plenty good for data entry forms. I saw a demo recently of a text box that rippled when you touched it with a mouse or typed in it. Please. RIA is extraordinarily good for displaying information that is well nigh impossible in HTML and JavaScript. Use it for those kinds of visualizations. Most of the RIA platforms now don't support web metaphors like bookmarks, or addressable URL's. There's no reason to completely discard the parts of HTML that work well for which it is designed. Use HTML for general interactions, and use RIA for sophisticated visualizations. And know going in that you've bought a platform that you're going to have to live with for a long time.

A slightly different version of this rant, more Silverlight focused, appears here. I was at a party at a friends house that had lots of .NET folks there, during the Microsoft MVP Summit. I was getting some impending dead-line work done and Eric was recording a series of podcasts, the tone of which can be summed up by "Silverlight will cure cancer, solve world hunger, and paint your kitchen for you". After he was done, I was quietly fuming and asked him if he wanted a contrarian view. That's what's on the podcast. You've been warned!

RubyNation

One of the interesting things that's happening in the Ruby community is the sprouting of regional conferences. Because Ruby is still nascent in the Enterprise space, it's hard to conduct conferences (especially regional ones like No Fluff, Just Stuff) because individuals probably have to pay for themselves (rather than having a corporation pay for them). This is a clear case of developers seeing the next thing they want to do, but companies lagging behind them. But Ruby (and Rails) has some pretty sophisticated stuff, which lends itself well to a conference. Thus, the rise of the regional conferences, many of them basically operating as a non-profit, trying just to cover expenses with the conference fees. And that describes RubyNation on August 1st & 2nd, where I'm delivering the opening keynote. It speaks highly of the Ruby community that the conference organizers are willing to put in a vast amount of effort (and believe me, putting on a conference is a huge undertaking) just for the love of the technology. That's a rare thing indeed, and shows what a wonderful place in general that the Ruby community is. I'm happy to speak at these regional conferences because I like the passion for technology on display. It's fun being around people who really care about technology, and love to debate it, discuss it, and generally wallow around in it (which is one of the reasons that I love ThoughtWorks so much). So, even if you have to get on a plane, come to Ruby Nation and wallow around with me. And, it that's no enough incentive, come because Stuart Halloway is making a relatively rare appearance as the closing keynoter. Should be a great couple of days.

Agile IT! Experience

I'm speaking at the upcoming Agile IT! Experience, in Reston from June 26 through June 28. Most conferences focus on one attendee demographic: developers, business analysts, managers, CIO's (which entails much golfing and little conferencing). But projects must encompass a wide variety of roles, all of whom must work together. The upcoming Agile IT! conference breaks that mold. It caters to all members of the project ecosystem. That means that managers will rub elbows with developers, business analysts can chat with testers, and use the synergy of their experience to both understand how the other half lives and pick up valuable insights from other people that will make their work better.

I really like these kind of mixed conferences. Too often, conferences are too homogeneous. Getting a group of people together that have different perspectives always broadens the perspectives of everyone. This new conference blends several normally separate worlds, enriching all of them. I'm looking forward to IT!

Book Review: Programming Groovy

In the movie 2001, A Space Odyssey, the director Stanley Kubrick spends a vast amount of time with lava lamp-style special effects. The last part of the movie is an interminable journey through the same scene with different colors. Kubrick would never make that movie now: at least a third would end up on the cutting room floor. But he was entranced with the shiny new technology and indulged it to distraction.

The same thing tends to happen when a new technology comes out. If you are an early adopter, you'll slog through the lava-lamp effects to get to the meat of the new technology. Groovy has followed this route. Because I've been following Groovy for a while, most of the previous Groovy books have been in two categories:

• wow, look at this new thing! Isn't it cool that you can do all this stuff, which contains useful information but also a fair amount of "look, she's walking upside down for 10 minutes" kind of stuff


• recipes for getting real work done (where Groovy Recipes falls, so I think it's very well named. I reviewed it just before this one.)
  

I don't mean for this list to sound pejorative: every new technology comes out with these books first: it's an inevitable part of the technology life-cycle for new languages. But eventually someone comes out with a book that no longer treats the new language like a shiny new thing, but as a serious contender in the language universe. And that's Programming Groovy by Venkat Subramaniam (disclaimer: I know Venkat, but you shouldn't hold that against him). It doesn't treat Groovy like a novelty act. It also doesn't provide recipes. Instead, it treats Groovy as a real programming language. I'll have to admit, this is the Groovy book for which I've been waiting.

Groovy is friendlier syntax for programming Java (I called it the real JDK here). Books about the practical aspects of Groovy are very important because, as a language, it resides in a unique place: it's a low impedance way to program the Java platform, and it displaces Java for lots of common tasks. But it is also a powerful language in its own right. Programming Groovy has 4 chapters on meta-programming Groovy, and another long chapter on building domain specific languages. That's meaty stuff. It never condescends or makes excuses for Groovy but treats it like a real language. It includes lots of material that's hard to find online (like how ExpandoMetaclass really works). This is going to be both a classic in the Groovy literature and an exemplar for describing the real power of new languages.

Book Review: Groovy Recipes

While I've been "away", hammering away at my own book project (see this blog entry for that history), several important books have arrived that I haven't had a chance to talk about. I'll cover them in chronological order. The first is Groovy Recipes by Scott Davis. This is the Scott half of a book project that he and Venkat Subramaniam started a while ago as a single book (disclaimer: I know both authors quite well), and they quickly realized that they were writing separate books, so they made that a reality (I'll talk about Venkat's book in my next post). Groovy Recipes does what the title says: gives you recipes for how to get stuff done in Groovy. But that's only part of the value of this book. It also teaches how to become an idiomatic Groovy developer. And that's incredibly important. The classic book on C, the K&R book The C Programming Language, did 2 things for C. First and foremost, it taught developers about the c programming language. But the second more subtle thing it did was to teach developers how to be idiomatic C programmers. I can remember reading the book and marveling at the conciseness of the code, which had as much to do with the way the language was used as the language itself.

Anytime you learn a new language, you have 2 battles: first, learn the syntax (which is the easiest part -- it's just details of how familiar concepts are expressed in the new syntax). The second battle is the more important one: how to become an idiomatic programmer in that language. Developers new to a language tend to write new code just like code from their former language, using new syntax. Only when they've had time to steep in the better, more elegant ways of expressing yourself in a new language do they truly become proficient. That's what Groovy Recipes does for Groovy developers. It shows not just the syntax, but how to idiomatically use that syntax to become proficient with Groovy. Groovy is a much more powerful language than Java. While you can take a Java source file and rename it with a groovy extension and have it still work, you're writing Groovy code like a Java developer. After you've seen and used Groovy for a while, you start writing code like a Groovy developer. The Groovy Recipes book is two things: recipes for using Groovy to solve problems. But, more importantly, it teaches idiomatic Groovy programming, which is the long-term benefit of the book.

The Productive Programmer - History & Future

No, I haven't fallen off the face of the earth. I haven't been blogging lately because I've been heads-down, finishing (finally!) The Productive Programmer. Understanding why it took so long requires some recent history.

Back in 2005, after having fully recovered from writing the Art of Java Web Development in 2003, I decided to look for a fresh book project. I started wondering if the world could use another book on Regular Expressions, other than the seminal work on the subject by O'Reilly. I asked a few people and the universal opinion was a resounding "No!": the current book is so good that it's pointless to try to write another. I was talking about it to David Bock, friend and No Fluff, Just Stuff colleague when I visited NovaJUG, the Java User's Group he facilitates in the DC area. He agreed with everyone else, and we started chatting about what we thought would make a good book. We had both recently observed developers struggling to make an IDE do something that was trivial on the command line, but the developers had spent their entire careers in graphical operating systems and IDE's, and couldn't bash their way out of a paper bag. We decided that it would be cool to write a book about command line tricks and techniques for developers, and that we would write said book. The original idea was to write a gigantic recipe book for programmer productivity. We contacted a publisher (who suggested the title The Productive Programmer), and we started gathering recipes and writing about them.

Then, 2 things happened. David left his job of many years and founded a consultancy, Code Sherpas, and instantly became 300% allocated. At about the same time, his wife Lorna became pregnant with triplets! Clearly, David now has his hands more than full. At about the same time, I realized that a book consisting solely of recipes would be the most boring book every written. But, by that time, I had also noticed some patterns in the productivity stuff in which I was now immersed. In fact, I remember the exact moment I realized that this book should show patterns (or principles) of productivity. I was in India, working on a ThoughtWorks project by day, and writing the book by night. I had some long conversations with some of the folks with which I was working (Hi, Mujir!) about this, and finally settled on the five principles of productivity (which later became 4). Instead of being a book of fish, I now had a fishing manual.

Of course, I've been busy as well, so the work on the book was intermittent at best. Plus the fact that the publisher was really expecting a recipe book, and it was no longer that. So, the publisher and I started going back and forth, wrestling over the format and content to try to mold it into something upon which we could agree. By this time, I had kind of taken over the book because David was so slammed. Eventually, I realized that no amount of massaging was going to create the book the publisher thought they wanted, so the publisher and I decided to part friends. I now had distilled the 5 principles down to 4 (I realized at some point that indirection is really just an aspect of canonicality) and written about them. While I was writing, I was also doing Productive Programmer talks at No Fluff, Just Stuff, honing the material that was perpetually going to be out RSN (Real Soon Now). I now had about 100 pages of refined material. But I also realized that the principles really only covered one aspect of developer productivity, the mechanical side. I also realized that I had been talking about the practical side of productivity in my older talk Clean Up Your Code and its modern sequel 10 Ways to Improve Your Code. That was the last piece. I contacted my now publisher O'Reilly with 1/2 of a productivity book and a clean vision for what the second half should be. So, from December until March this year, I wrote the 2nd half. And, fortunately, David agreed to write the forward of the book, which gave a pleasing resolution to the original vision we both had.

For all those long suffering attendees of my Productive Programmer talks at No Fluff, Just Stuff for the last 2 years: the book is ready. It's in copy editing now, and should be out soon. RSN. For real this time.

This is a thanks to all the people who've attended the talk over the last couple of years. Your questions and responses made the book better, and now you can hold one in your hands. And, now that I'm back from intensive writing, ready to reengage the blogsphere with a vengeance.

Rental Car IT

I travel a lot. Mostly, when I travel and need a car, I get one through one of the major vendor's premiere customer program, meaning that I get to walk right to the car and drive away without much formality. Which is a good thing, because every once in a while, something is amiss and I have to go to the counter. And that entails dealing with rental car IT.

The amount of information you need to rent a car seems pretty small. Even if it's not, it's very well defined. You'd think that they would have the process honed; it is, after all, the primary thrust of their business. But watching the sheer number of keystrokes that the counter attendee must perform to put me in a car is astounding. The same is true when you bring it back. It's like they are typing the great American novel. What could possibly require so typing? They know who I am. They have all my credit card, insurance, and driver's license information (enough that they'll usually just let me get in a car and drive away). This isn't confined to a single rental car company either. I've dealt with a bunch of them and they all have an enormous amount of data entry.

Unlike a lot of problem domains in which I've specifically worked, I don't know for sure what's going on for rental car companies. But here's what I suspect: their IT infrastructure is strangling them. Ironically, many of the companies that embraced IT very early on (i.e., in the mainframe era) are suffering a lot now. Much of the interest in SOA derives from the desire to get out of the deadly embrace of fossilized, astoundingly brittle IT infrastructure.

Closer to home, I've recently been doing some consulting at a large company, helping them define their evolution towards a better tomorrow. I was talking to one of their senior IT staff, and I mentioned that it seems like they don't have a really good idea what their users need software for, and that maybe we should go talk to them. He looked at me like I had a new eye sprouting on my forehead, and said to me "We've tried talking to them -- they don't know what they want, so we have to define it for them. You can't be so naive to think that we can actually talk to the users." At this large enterprise, software is its own ecosystem. The users of the software almost never come up in meetings. Instead, it's a gigantic plumbing exercise. What's ironic is that this particular company is primarily run on information. Yet, they are so far down the rabbit hole of plumbing and complexity, they have managed to create mountains of rubbish. They are in the deadly embrace of accidental complexity, not essential complexity. My coworker and I identified their IT needs for the entire enterprise as small to medium, if this were a green field. But, of course, they have information trapped in mainframes, in several different formats of databases, in packaged applications, and scattered hither and fro, like lots of enterprises.

By way of trying to get them to rethink some of their decisions, we tried (and were marginally successful) in getting them to define some core principles, like simplicity and flexibility. What was funny about that exercise were the looks we got from the no nonsense King of IT: "Of course, we want things to be simple and flexible -- why are you bothering to tell us this?" Yet, in the next sentence, they are talking about spending 3 million dollars on a packaged application to help them with one small part of their business, rather than building it themselves (which we all thought would be cheaper but take longer). That's $3,000,000. But, of course, the packaged application talks directly to their databases, meaning that we can no longer freely make changes to the database without breaking the package, meaning that we can't evolve the database, meaning that we've lost both simplicity and flexibility. Over and over, they complain when we talk about rethinking their priorities, then turn around and make the same decisions that got them where they are now. Frustrating!

At another company I did consulting for years ago, they had a special mainframe application that handled one part of their business. I don't know how much it cost, but it had to be a lot because their vendor came to them one day and said "Look, we really just can't take any more money -- we're bloated and frankly we can't figure out how to spend all you've given us already." Instead of taking this opportunity to rethink how this part of their business works, the found another mainframe application that did the same basic thing, and spent 43 million dollars changing around the life support for this thing. Fundamentally, the problem they were solving wasn't that tough. I know; we were working on a piece of it and got a good feel for the whole thing. They were so drowning in the accidental complexity of the way they had always done it that they couldn't see the actual problem anymore. I walked into a conference room at one point, and saw a diagram that literally covered the entire wall with boxes, lines, and 8-point font describing the enterprise architecture (no, sorry, Enterprise Architecture). When one of the client developers walked in, I said "Wow, it's a good thing you guys dismantling this mess" to which he replied "No, that's the new one we're going towards". Decisions like this mean I have to spend my time in long lines in places like rental car counters.

Going back to first principles is hard, and many companies think it's too late. I've been involved on projects where getting back to a simple solution takes years. But it's worth doing. Otherwise, the company will drown in self-inflicted complexity, when IT becomes a governor on the business rather than a strategic advantage. When that happens, some other company with nimble IT will eat their lunch. Software can be either an asset or a liability.