Don't Be a Hater -- Think Different

People still fear what they don't understand or what's not familiar. When I arrived at the SOA conference in Kuala Lumpur a couple of days ago, I was met by the hotel's AV guy to hook up my Mac to the projector. I used the normal elaborate procedure I usually do to sync my Mac with a projector: I plugged the projector into my machine. But, unusually, no signal. I tried Display Preferences, changing the resolution, the number of colors: nothing. He was convinced that my exotic, bizarre machine/OS was the problem, and I kept trying to convince him otherwise. Finally, I persuaded him to go get another cable, which he reluctantly did (I don't know any Malay curse words, but I'm pretty sure I've now heard some). You can probably guess what happened next: new cable, perfect signal, at all my original settings.

Which reminded me of another conversation I had a couple of years ago with a friend in Singapore. We were sitting around talking about computers, and he made an off-hand comment that he didn't like Macs because he thought they were unintuitive, but he thought Windows made perfect sense. So, I asked him "So, you're telling me that the operating system where you click on the Start button to turn it off is the more intuitive on? I think you're just used to it", to which he replied: "You're right, I'll shut up now". I saw him again last night in Singapore, and we were catching up on all sorts of stuff. And you know what he told me? He just got a new machine with Vista on it, used it for 2 weeks, and returned it to Dell. He told me that he can't wait until his laptop finally dies because he's going to get a Mac. The reason for the change? He's now addicted to his iPod, and it's made him realize that Design Matters.

I can't resist beating everyone on the head with the moral: Don't succumb to FUD because something is different. And, in the tortured grammar of the old Apple campaign, Think Different. Because Vista is so different from previous versions, it may be the best thing that ever happened to Apple. If you're contemplating a change anyway, why not look at the entire field so that you end up with the OS equivalent of an iPod, not a Zune.

Pontificating about SOA

What else is there to do about SOA? Back in December, Mark Richards (Enterprise Architect at IBM) and I sat down and recorded a video PodCast about SOA (which we informally named "Taking Back SOA"). The results has now appeared at the No Fluff, Just Stuff web site. Mark and I have a very pragmatic approach to SOA, and we both hate the level of hype that appears in that whole space. He and I had a great time recording this video, which proves once and for all that IBMers and ThoughtWorkers can get along after all!

No, I Won't Stop Talking about IntelliJ!

During my No Fluff, Just Stuff talk on The Productive Programmer, I got a comment at the Minneapolis show to "stop showing us IntelliJ shortcuts -- we all use Eclipse!" And, Venkat Subramaniam blogged about the whole Eclipse vs. IntelliJ debate that came up at the expert panel in that same city. Venkat quite eloquently gives his reasons for choosing IntelliJ: it simply makes him more productive. And the same is true for me. I've used all the major Java IDE's in anger: NetBeans, JBuilder (I used to be considered a JBuilder expert, but I got over it), Eclipse, and IntelliJ. For me, IntelliJ works best. Period. In fact, I think that IntelliJ would land in my top five pieces of software of all time list. I also edited the No Fluff, Just Stuff Anthology chapter on IntelliJ tips and tricks, just out in treeware.

There are actually 2 IDE Tips and Tricks chapters in the anthology. When I sent out call for contributions from the authors and friends for IntelliJ tips, I got a flood of them, all very cool (and a few that I didn't already know about, like the Key Promoter). Ted Neward (who edited the Eclipse chapter) and I sent out the same call for Eclipse tips and tricks, and we got none. We sent out another call, and a few trickled in. And that is reflected in the book. I'm sure we're going to get grief over the IntelliJ chapter having more cool stuff. But that's really the whole point: like the preponderance of Macs on the No Fluff, Just Stuff tour, the people who use IntelliJ are passionate about it, because it exudes excellence. Like Venkat says, many people using Eclipse are in a bad arranged marriage. It's hard to drum up passion for an arranged marriage.

I feel like it is my duty to try to turn people on to things that make their life better. That's part of what being a speaker is about. So, I'm not apologetic about proselytizing IntelliJ. Every-time I find a tool that I think will make developer's lives easier, I'm going to talk about it. And, if I develop a passion about it, so be it.

PodCasting About Groovy

A couple of weeks ago, I recorded a PodCast for AboutGroovy.com, talking about (obviously) Groovy, DSLs, testing, and how to insinuate Groovy into your company's infrastructure. Basically, Scott Davis and I had the kind of conversation we have all the time at No Fluff, Just Stuff. The only difference is that he was recording it. It was fun and the content will come as no surprise to anyone who knows me.

Being a Consultant Makes You Tough (or Stupid)

Since working for ThoughtWorks these 2 years, I've gotten much tougher in the face of being able to work on short or bizarrely interrupted sleep. Case in point: I left Minneapolis (after speaking at the sold-out No Fluff, Just Stuff Twin Cities Software Symposium) on Saturday evening, dashing from my last session at 4:45 straight to the airport. 8 hours later, I was in Amsterdamn, with a 2 hour layover. 12 hours after that, I'm in Kuala Lumpur, arriving at 6:15 AM. I probably got about 8 hour of sleep, but never more than 2 hours at a time. I'm now exactly on the other side of the world from where I live: 12 time-zones away. I cleared customs, got my suitcase, and headed for the car service the conference had arranged. Traffic was awful, and combined with the distance of the airport from downtown KL, I arrived at the hotel at 8:35 AM...and the conference starts at 9 AM with me facilitating. Quick shower, dash upstairs, and I'm ready to go at 9 AM sharp. I then proceeded to talk on and off for 8 hours. I managed to stay up until after 8 PM. It's now the next day, and I feel fine. I'm apparently adjusted to the new time zone (I sleep soundly last night, interrupted only by my phone ringing at 11 PM (or, 11 AM in the states)) which I promptly ignored.

Two years ago, I could have never done this. Just part of the implicit training all the travel and distributed work instills. But there are benefits as well. Here is a picture taken just outside the hotel's meeting rooms.

The Elusive Right Click

Since he got his Mac, Venkat Subramaniam and I have been playing around with pushing the envelope on human computer interaction and productivity as hard as we can. He finds a cool new keyboard shortcut and can't wait to tell me, I learn a new QuickSilver bit of magic and can't wait to tell him. The Holy Grail of this kind of pursuit is finding a way to generate a mouse right-click using only the keyboard. Of course, Mac OS X is pretty friendly to use the track pad, but that's not enough for us: total keyboard control is the goal.

And yesterday I stumbled upon the Holy Grail. I was in the process of shaving a yak, and was waiting for something to finish, so I decided to solve this problem Once and For All. I did a bunch of Googling and experimentation and stumbled upon the solution. Go to Universal Access and turn on Mouse Keys. This the the accessibility option that allows you to drive the mouse strictly from the keyboard, using the embedded keypad. Once you turn that on, you can use the FN-I key to click the mouse, which means that you can use FN-CTRL-I to right click. It's not perfect (it clicks where the mouse current resides, not where the keyboard focus lives) and it precludes using the embedded numeric keypad for doing 10-key entry (which I never do anyway). You can turn it on and off by clicking the OPTION key five times (this is a setting on Universal Access as well).

But we're happy. Venkat got as excited as I've ever seen him when I showed him this morning; I was looking forward to show it to him all day. Ah, simple pleasures!

Don't Misquote Me to Create a Straw Man!

OK, I can't let this pass.

The ServerSide wrote an article, summarizing both mine and Venkat Subramaniam's talks at The ServerSide Symposium last week. It's a reasonable summary, with a few details left out (that's why it's a "summary").

But then, Cedric Beust takes the summary and constructs a agile development straw man to beat up. And, like many straw man arguments, he takes lots of stuff out of context and makes his own conclusions not supported by the original talk.

The first thing he gets wrong is the fault of the summary. Early in the talk, I clearly state that the best way to get good software is to interact directly with the users. And I give an example from my project history of the best project experience I every participated in, where the developers literally sat in the middle of the users. Every time we had a question, we just got up and resolved it directly with the users. It was project heaven.

But most corporate environments won't give you such direct access to the users, because the users are after all there to get work done. Thus, you must have user proxies. And that's where the business analysts come it. Perhaps at ThoughtWorks, our business analysts are different from the "typical" ones (I know our project managers are). The best business analysts are direct proxies for the users. They understand the users concerns and a little about technology. During the talk I also made the point that good business analysts prevent "paving the cowpath", suggesting innovative business solutions to problems rather than "that's the way we've always done it".

When I say that business analysts participate in the estimation process, that's because we can't get the users directly.

Do you know the difference between a good developer and a bad developer? A good developer can give you an estimate of the time needed to complete a task. And the better that developer is, the more accurate their estimate will be. If I ask a developer "How long is it going to take to do this?" and he answers with "It's very complicated", I want him off my team.

Another point I made in my talk is that, regardless of developer, you can't ask developers "how long will this take". Every project is different: in a 2 man project with no meetings and direct access to users, each developer will get more done in less time. In a project with 16 developers and a 2-hour status meeting every day, each developer will be much less effective (this has been known since Brook's The Mythical Man Month). But that is constant is the relative complexity of the story you are trying to complete. Relative to the other stories, not the entire universe. This allows developers to hone their estimation skills because it cuts down on the number of variables they have to hold in their head. This is the closet you can get to an objective measurement of the work required to complete a piece of software.

We don't need agile consultants and book authors to sell us vague and unproven metrics along with rigid guidelines that your team must embrace without any questions.

Ironically enough, we agree wholeheartedly about this, but he doesn't seem to know that this is exactly the point of my talk at The Serverside Symposium. The whole point of the talk was that we need real metrics like passed tests, real reconciliation between estimates and actuals, and binary completion criteria. The article makes that pretty clear, but that doesn't contribute to the weak straw man, so Cedric conveniently left that out.

What's most frustrating about Cedric's rant is the implicit assumption that "agile" is this vague concept that no one seems to be able to define. Yet, at ThoughtWorks, every single project is agile to some degree (and where we control everything (like fixed bid projects), it's pretty close to Extreme Programming). And we have a really high success rate, way above the industry average. I've been around for a while (one of my colleagues once told me that I was old enough to "add diversity to the company"), and I've used a bunch of different methodologies. One of the reasons I'm at ThoughtWorks is because we use proven techniques for building software, and we're damn good at it, making it a much less frustrating place to work.

DSL Podcast on No Fluff, Just Stuff

As my regular reader(s) know, I'm big on Domain Specific Languages, and have been talking and writing about this style of development for a while. During the course of last year, we recorded some PodCasts at some of the No Fluff, Just Stuff shows. One of those shows was Chicago, where I recorded a PodCast about my feeling about DSLs and this approach to building software using this technique. The PodCast has now appeared on the No Fluff, Just Stuff web site, for your listening pleasure.

Anthologization Redux

Well, it's that time of year again: the No Fluff, Just Stuff Anthology, Volume 2 (The 2007 Edition) is at the printers, undergoing the conversion from thought to dead trees.


Just like the blurbage on the back says:

Once again, some Sixteen of the world's best trainers and speakers are writing chapters on things they care passionately about. You'll find topics from the latest conferences including Groovy, JavaScript, Continuations, Web services and REST, JVM Byte Code, and Agility

These essays are a summary of the latest thinking in the industry, and range from the philosophical to the tutorial, covering the topics that the writers felt were the most important for readers today. If you feel like the neatest technology and latest ideas are passing you by, this book can help bring you back you to speed.

It's all good stuff, without any fluffy filler, as these essays are based on presentations given at the incredibly popular "No Fluff, Just Stuff" symposium series. Twenty-six times a year, the symposium visits a city and the speakers and attendees share ideas and perspectives. The speakers are all internationally known experts in their field.

So, to out and buy one as soon as possible (in a book store near you in early April). Or, order it directly from the Prags or at Amazon. In fact, I recommend that you buy two in case you loose the first.

Of course, I was intimately involved in its creation, but this is a really entertaining read (the main reason I like editing the Anthology is because it means I can read the essays as soon as possible).

Enjoy!

Garrulous Software

A particularly annoying characteristic of software these days is excessive chattiness. This occurs at both the user and developer level. In fact, one of the things I prefer on the Mac vs. Windows is the lack of meaningless messages the Mac generates (No, I do NOT want to clean off my desktop right now!). Pestering messages at the OS level distract from your attention and diminish your productivity. In The Humane Interface, Jef Raskin discusses the locus of attention, which is the work you are trying to perform. Anything that moves your locus of attention had better be a) relevant to your work and b) urgent and important. In fact, I think its a good idea to turn off the automatic notifications of email arrival, especially if it interrupts real work. Experts on "flow" maintain that it takes up to 20 minutes to get back to that deep concentration state, and it gets harder as the day goes on to overcome the inertia required to get back to that flow state.

The problem in the development world is much worse. It seems like the norm now to generate tons of meaningless noise. Think about application server startup, scrolling messages into the console faster than you can read it. 99% of that information is just the application server saying, over and over again like an idiot, "I'm OK...I'm OK...I'm OK.............I'm OK" (that last one was an EJB loading). The only thing that allows you to see errors is the massive stack traces that come from errors in the J2EE world. In fact, this problem is so bad that developers have taken to dubious practices to make their own messages to stand out from the flood of useless information. Admit it...you've put a Systen.out.println() in your J2EE code to debug it (a whole other subject). And, to make yours stand out from the noise, you put 30 or 40 "~"'s in front of it. Of course, your coworker is doing the same thing, and they use 30 or 40 "#"'s for theirs. Before long, application servers look like they have Tourette's Syndrome, spewing mostly meaningless noise.

My pair and I encountered this very problem recently. We were working with client code that makes heavy (handed) use of Log4J to spew out messages to the console. Unfortunately, that makes for ugly unit test results: you can't see the interesting stuff for all the immense noise being generated by the code under test. In this case, it wasn't as simple as turning off the logging level (the code under test was creating an instance of something that had its own logging stuff buried deep inside). So, after a little thought, we figured out how to shut it up.

In out test case, we unplug the normal output stream, like so:

protected void setUp() throws Exception {
  super.setUp();
  originalOut = System.out;
  System.setOut(new PrintStream(new DumbOutputStream()));
}

And, in tearDown, we put it back:

protected void tearDown() throws Exception {
  super.tearDown();
  System.setOut(originalOut);
}

Our "DumbOutputStream" isn't stupid, just quiet:

 private class DumbOutputStream extends OutputStream {
   public void write(int b) throws IOException {
     //do nothing, because I'm dumb.
   }
 }

This effectively shut off the fountain of noise, leaving the testing framework's output (which occurs on System.err, not System.out) alone. Sometimes, you have to work hard just to shut something up.

Inside Edition: Star Wars

Warning: this blog post is a complete waste of your time!

On the Relevance site, I saw a link to this fascinating analysis of the connections between the first Star Wars trilogy (episodes IV-VI) and the second one (episodes I-III). As much as I'm loathe to admit it, I've done some thinking along these same lines, especially since 2 things have recently happened: 1) I got a new HDTV and 2) HBO has turned into the "All Star Wars Station" (but only for episodes I and III -- they must not have rights to II). You should probably read the analysis before you go on (or it won't make much sense). I'll wait.

In fact, the only flaw I can find in the analysis is the fact that the Jawas weren't at first going to sell R2D2 to the Skywalkers -- it was only after the other similar droid blew up (maybe R2D2 did something to him in the hold of the Jawas' ship?) But it kills the idea that the reason they ended up at the Skywalkers was some sort of deal with the Jawas (unless they double crossed him). See, I told you this was a waste of time, right?

Actually, I distinctly remember interviews with Lucas back in the late 70's where he talked about a trilogy of trilogies (it was supposed to go episodes IV-VI, I-III, and then VII - IX). He has since retracted that statement (and claims he never made it). Whatever. Given how much work it is, I completely understand.

But I always thought that it would be cool in episode IX for C3P0 and R2D2 to suddenly reveal that they are in fact the keepers of the force, much like some of Asimov's robot stories where the robots turn out to be the guardians of mankind while pretending to serve him. And, if you take C3P0 out of the equation (in light of the analysis above), then R2D2 can be said to be the guardian of the good part of the force. That would be cool!

When I want to waste some more of your time, remind me to tell you about the plot idea I have for the origin of the Borg...

More Sony eReader Pix

By popular demand, I'm posting a few more pictures of my Sony eReader, to convey a better impression of the resolution modes I described in my previous post.

The first shows the smallest eBook resolution:



The second shows the largest eBook size (Mr Magoo Mode):



The third shows a Pragmatic Press PDF (Best of Ruby Quiz), in the best viewing mode (rotated to landscape, zoomed in to text width):



I hope that satisfies everyone's curiosity! If you want to feel and touch one, I saw them on sale at my local Borders in Atlanta last weekend.

Sony eReader

Those who know me know that I'm a gadget nut, and I've gotten a few gadgets lately that fall into the category of essential for my on-the-road lifestyle and of interest to software developers and other geeks as well. One of them is the Sony eReader. This is the first real application of digital ink, which has been The Next Big thing for several years While it looks like a monochrome LCD display (with no back-lighting), digital ink acts more like real ink in that it doesn't consume power while it's being displayed. Most LCDs need a constant (very low level) charge to keep their dark bits aligned. With digital ink, you just zap them once and they stay in place until you zap them again. The obvious use of them in a digital book reader makes perfect sense: it consumes no power while you are actually reading the page, just when you turn the pages.

The Sony eReader was announced at the beginning of 2006, and was originally going to be available in the Spring of last year. Fast forward to November, when they actually shipped (I got mine late November, and I was on the list of "ship it too me right off the assembly line". Here's a picture:



The Good
Reading eBooks on it is an awesome experience, pretty much all I hoped for. The screen is highly readable as long as you have light (it does not have a back light). Essentially, if you have enough light to read a regular book, you can read this one. Even in low light it isn't bad because you have 3 zoom levels for eBooks: small, medium, and large (Mr. Magoo could read the large without his glasses). The page flips are slow because of the digital ink, but it's not really noticeable. I quickly forgot that I was reading something on a new fangled device and just enjoyed it, and have subsequently read more than a dozen books on it. The battery life is stunning: I used it for an entire week in Singapore, reading a couple of hours a day, without recharging it once (and that included 2 marathon reading binges on the 26 hour flights there and back). The eBooks (and even PDFs) take up very little room. It comes with about 100 Mb of storage; I immediately put a 2 Gb Memory Stick in it. I guesstimate that I can probably get 1000 books on this puppy.

The Bad
One of the great appeals for me was the ability to put PDFs on it. I carry (or would like to carry) a fairly sizable collection of reference books with me, in addition to whatever I'm reading at the moment, and lots of books (especially technical ones) exist on PDF. Alas, the reading experience with PDFs leaves something to be desired. Unlike eBooks, the eReader can't reflow PDFs, meaning that you can basically see them in 1 of 2 sizes: regular (the entire page) or zoomed (just the text on the page, eliminating the margins). The text of most PDFs is still too small for portrait mode even in the zoomed state, so I generally flip it to landscape. One of the annoying bugs bites you here: when you flip pages on PDFs in landscape mode, it re-sets itself to regular mode but still thinks it's in zoomed. That means to be able to read the page, you have to flip it back to regular (for real), then flip it back to landscape. That means that every time you flip pages, it's a 3-press operation. Which wouldn't be so bad except for the glacially slow refresh rate for the digital ink (which is hardly noticeable for a single page flip). Once they get this bug fixed, PDF's will be reasonable on this device, but painful for now.

The Ugly
The selection of eBooks is pretty small right now, but growing fast. As you would expect, there are a fair number of science fiction titles, including Neal Stephenson's whole catalog (which I have dully downloaded and and synced onto my eReader). The worst part of that whole experience, though, is the Connect software that comes with it and manages both syncing with the device and shopping at their on-line bookstore. Strike 1: Windows only, so I have to crank up Parallels to access it. Strike 2: Think iTunes written by a high school student who's just learned VB. It's awful and clunky. The should have picked a reasonable starting place (like Eclipse RCP) rather than reinvent a buggy version of an application that needs a file system view, a HTML-centric content pane (or pain, in this case), and standard menu stuff. Strike 3: buggy, crashing at the drop of a hat. One of the few options on the menus is "Update", which I access frequently to try to get a better version. While it works mostly, it also locks up on a regular basis. At least the syncing part pretty much works and is fast. It really shows, though, how much you take something like iTunes + iPod for granted until you see an amateurish version.

The Bottom Line
The above notwithstanding, I love this little thing, especially for eBooks. If they would get the PDF bug mentioned above fixed, it would be Good Enough for PDFs too. Of course, what I would really like is the ability to reflow PDFs, but thats much tougher. If anyone reading this knows of a PDF to eBook converter, please let me know...I've searched in vain. The Sony eReader has some pain points (like the PDF bug) for a version 1.0 product, but it still a great addition to my collection of gadgets.

Why I Hate Christmas Music

Most of my family thinks I'm a curmudgeon because I hate Christmas music. Generally, I don't bother to go into the full details of why I hate it because it is long and drawn out, and chances are slim that they would understand anyway. But here's why.

Music has a special place in my life. Like a lot people in the software industry, I have an intense relationship with music. Ever since I discovered music in a big way when I was in the 7th grade, it has been a constant companion. Literally. I always have some music playing in my head, always in the background. There is no way for me not to have music playing in my head. I wake up with music, spend my whole day with it, and go to sleep at night with it. And therein lies the problem.

I hate catchy tunes because the stick in my head and won't go away. What most people like about pop music is the very thing that makes me dislike it: the hook. The problem is that those little snippets of music get stuck in my head and persist. Hours later, I find the same track playing over and over, an increasingly irritating background noise. After a while, I have almost a sore spot in my conscience, a groove worn deep by the same little track playing over and over. The catchier the tune, the harder it is to exorcise. It's like a cut on the roof of your mouth: constant low level irritation.

This explains several things about my music taste. It explains why I have 1000+ CDs and counting: I must have variety. It also explains why I like so much music that most people find disturbing and discordant. I crave complex music all the time. My wife, Candy, complains that I don't like any "happy" music because I have such a taste for the unusual: the anti-catchy tune.

And that also explains why I don't like Christmas music. By definition, all Christmas music features catchy tunes, designed for humming and singing along. When I was a kid, I enjoyed it as much as the next person. But is has a cumlative effect. Every year, the grooves in my head worn deep from the past get worn deeper. I find myself in a constant bad mood around Christmas because the music is inescapable. This last year, they were playing it on the airplane as they taxied, at exactly the time you are forbidden to use some other music player to drown it out. My head was filled with those tunes for hours afterwards, boring their way through my gray matter. I defensively wore my iPod in every store that I went during the holiday season

Christmas music isn't the only thing that affects me. At the client where I am currently stationed, some fool has his cell phone play "When the Saints Come Marching In" as his ring tone. For the first few weeks I was here, I would wonder why, at the end of the day, my head was full of that irritating tune, playing over and over, drilling its way through my head. It's like inadvertanly stepping in something sticky, and now every step pulls irritatingly on your shoe. I figured that it must be a cell phone somewhere, so I started listening for it. Sure enough, someone in the vast cube farm over my right shoulder gets about 10 calls a day, polluting the air around me with that insidious song. I wondered why coming to work here put me in such a bad mood: now I know. Because I know it's there now, I try to fight it off everytime it rings with some other music that is soothing (to me at least) that I can summon from my mental reserves. It's not cool here to were my iPod or I would, all day, every day. And the worst part is, I can't really complain because I can't find this person (the office is large enough so that I can't home in on the signal before they answer it) and they would think I'm crazy. Just like my family thinks I'm a scrooge.

Technology Snake Oil Part 11: Customizable Rube Goldberg Machines

I've found myself more and more talking to people about SOA because of my background with distributed computing. Over and over, in these discussions with CIO's, CTO's, and CCYAO's, they keep talking (without realizing it) about Customizable Rube Goldberg machines.

Rube Goldberg is a cartoonist whose name made it all the way to the dictionary:

Rube Golderg - n. A comically involved, complicated invention, laboriously contrived to perform a simple operation.


Rube Goldberg was a Pulitzer Prize winning cartoonist, sculptor, and author who lived from 1883 - 1970. He is well remembered for his cartoons (thus the dictionary entry), some of which everyone has seen (maybe without realizing it). Here is Rube Goldberg's "Simplified Pencil Sharpener":



Many SOA architectures look just like this diagram, with similar unintentionally ironic names. As I wrote before in Entropic Software, software tends towards complexity. It seems doubly so that enterprise architecture tends towards (frequently needless) complexity. Every SOA pursuit I've ever seen could stand some significant simplification. Of course, most consultants won't say that; they view monstrously complex software as job security. That is perhaps one of the differences from mercenary consultants who are only in it for the buck (complexity == $$$ + long periods of time == job security). If, on the other hand, you have someone who is trying to implement what you need, the tendency should be towards simpler architecture and systems. This isn't a slam against big consulting firms (I know some guys who work for the biggest who really care about what they do, and they would agree with my assertion).

The Snake Oil here comes from C(x?)O's who believe that Rube Goldberg-like complexity is inevitable, and this myth is perpetrated by mercenary consultants. Like Rube's "How to Tee a Golf Ball without Bending Over":



The key to successful distributed computing lies with extreme simplification. The most scalable distributed architecture in the universe (as far as we know) is based on a very simple protocol: HTTP. The key to successful SOA endeavors is two-fold: simplicity and testing.

You can read more about Rube Goldberg and see a whole gallery of his work at www.rube-goldberg.com.

Writing Assignments

I haven't been blogging a lot lately because I've so tied up with other writing stuff. I have a huge number of writing projects ongoing. Ironically enough, I've been writing more than ever, just on longer-term stuff than blogging (and, for various reasons, my primary blog writing time, which is sitting in airports, has been down lately). Here are the projects:

• I'm editing the No Fluff, Just Stuff Anthology, Volume 2: The 2007 Edition as we speak. Just like last year, this one is filled with contributions from No Fluff, Just Stuff authors (14 of them this year) ranging from Web Services, language stuff, testing, agility, persistence, and a whole bunch more. We've also retained the very popular The Authors Speak chapter, where the authors talk about books, favorite tools, and (new this year) favorite travel horror stories. We've also added a couple of collaborative chapters, one on Eclipse Tips and Tricks and another on IntelliJ Tips and Tricks, with contributions by authors who use those environments. This one is bigger than last year's, weighing in at over 350 pages. It'll be out in March of 2007.
  


• 
  The Productive Programmer, for Pragmatic Press, is the book David Bock and I have been working on for about a year. We keep coming up with good ideas and our writing time keeps getting OBE (Overtaken By Events). But, he and I are really starting to crank out some pages because we really want it out in the first half of 2007. Look for it to pop up on the Pragmatic Press website soon as a beta book.
  


• 
  I'm also involved in a project with 3 other authors (Zak Tamsen, Jeremy Stell Smith, and Joe O'Brien) on writing DSLs in Ruby. Frequent readers of my blog know that this is a big topic for me, and my co-authors have come up with some awesome examples. This book is also for Pragmatic Press, and we've been cranking away at the pages recently, after spending several months discussing and generating examples. This book will blow some people's minds!
  


• 
  I'm also contributing to another anthology which shall go unnamed at the moment. Thankfully, that was just a couple of articles (one solo, one collaboration) that is done and off my plate for now. I wrote about Polyglot Programming, greatly expanding on the ideas presented in my blog entry of the same name.
  

Think I've got enough writing pending? Whew! Hopefully, if it doesn't kill me, I'll have 2 books and 2 anthologies out in 2007.

Finding the balance between short-term, idea fountain type writing in blogs and longer term, more cohesive writing for books is an increasing challenge for those of us who write a lot. Some of my colleagues (like Jay Fields) have essentially written a book, one blog entry at a time. If he published his blog between covers, he'd have one of the influential DSL books on the market. I've been trying to talk him into doing just that. It just goes to show how something as staid as technical publishing is not immune to seismic shifts because of the very topics that appear in their books.

ClearType

My friend and college Karan scolded me the other day when I told him about ClearType, which every user of Windows should use on their laptops. He was scolding me because I hadn't blogged about it, and he and I see each other rarely these days (as I'm no longer in Chicago). So, this is for you, Karan. I'll try to be better in the future when I find stuff like this.

ClearType is one of the great innovations produced by Microsoft R&D. Microsoft has a massive R&D effort world wide. Last year, I attended the Microsoft Tech Summit, and some of the coolest stuff we saw came from the head of R&D's presentation. ClearType is a utility that you download from Microsoft's site (here). It does sophisticated font smoothing, making fonts look much better on LCD displays. I'm not nearly so sensitive to fonts as some of my more aesthetically inclined colleagues (hey, David F., I talkin' about you), who can tell you in minute detail about kerning, anti-aliasing, and a bunch of other arcana. So, it's a big deal that I can tell that ClearType makes a noticeable difference. It makes the fonts look less jagged, and in the latest versions, it allows you to adjust the effect to get the best possible display.

If you are using Windows (still), and especially if you are using a laptop, you should download ClearType and give it a try.

Ruby, Meet the Enterprise

A lot of people (myself included) are convinced that Ruby is going to be the next major language (regardless of the platform it runs upon: native, JRuby, or the CLR). And, consequently, Ruby will have a major impact on enterprise development. In fact, I think that SOAR (SOA + Ruby) will be hugely popular in the coming years. As I've stated before, Ruby is the revenge of the Smalltalk crowd. It has a similar feel to developers but isn't hamstrung (like Smalltalk was) by proprietariness and expensive tools. Where Smalltalk failed, Ruby will succeed. Ruby is perfected positioned to become a major player in the SOA space: loose typing == flexibility, which is what SOA is all about.

Interestingly enough, if you look at the guys who were really into Java in 1995 and 1996, they are almost all heavily involved (and mostly billable now) in the Ruby world. Of course, this isn't an accurate barometer, but there is no good way to tell what is the Next Big Thing. Looking at people who've identified it before is as good a way as any.

Anticipating Ruby's move into the Enterprise world, next year features erubycon, the first Enterprise Ruby Conference. This is highly important to the Ruby community who wants to promote Ruby in the enterprise. Having a conference dedicated to this topic helps validate both Ruby's readiness for the enterprise and vice versa. I predict that, like RubyConf, this conference will be small this year, and in 5 years it'll be massive.

Dynamacism

The Pragmatic Programmer contains the outstanding piece of advice that you should learn a new language every year. It not only gives you more tools to apply to problems, but it encourages you to think in different idioms. Every language has its own set of patterns and styles (the original Kernighan and Ritchie book on C, known affectionately as the "K&R" book) was as much about how C should look as what it did. People still talk about the "K&R style"; they defined the idioms of C along with the language. Learning new idioms and styles makes you a better developer, thus the efficacy of the Prags advice.

Here's a recent example that I perpetrated. After a stint in .NET and Ruby on Rails, I'm back on a Java project for a while (and coding again in my beloved IntelliJ, even if it is on Windows). I ran across some code that caused my refactoring alarm to go off. Here's a snippet:

  
public void record(String toBeRecorded) {
    MessageWriter messageWriter = null;
    try {
        messageWriter = new MessageWriter(_destination);
        messageWriter.write(toBeRecorded);
    } catch (RuntimeException rx) {
        throw rx;
    } finally {
        if (messageWriter != null)
            messageWriter.close();
    }
}
public void record(List<String> listToBeRecorded) {
    MessageWriter messageWriter = null;
    try {
        messageWriter = new MessageWriter(_destination);
        for (String s : listToBeRecorded)
            messageWriter.write(s);
    } catch (RuntimeException rx) {
        throw new RuntimeException("Cannot write list of messages");
    } finally {
        if (messageWriter != null)
            messageWriter.close();
    }
}

This is an overloaded method that does basically the same stuff before and after the important stuff (writing a single message or a list). Because I've been in languages with closures for a while, I refactored it thusly:

public void record(final String toBeRecorded) {
    recordMessage(new Runnable() {
        public void run() {
            _messageWriter.write(toBeRecorded);
        }   
    });                                                   
}
public void record(final List<String> listToBeRecorded) {
    recordMessage(new Runnable() {
        public void run() {
            for (String s : listToBeRecorded)
                _messageWriter.write(s);
        }
    });
}
private void recordMessage(Runnable recordingStrategy) {
    try {
        _messageWriter = new MessageWriter(_destination);
        recordingStrategy.run();
    } catch (RuntimeException rx) {
        throw new RuntimeException("Cannot write list of messages");
    } finally {
        if (_messageWriter != null)
            _messageWriter.close();
    }
}

This is basically just the Command Design Pattern. But before I was using closures on a daily basis, I never would have thought to implement it this way. I would have created some additional classes in their own files, created a formal implementation of the Command pattern, and a lot of other excessive ritual. Of course, if this got much more complex, it might need that ritual but, in this case, I was able to consoliate all that open and close code in a single place (which made things DRYer as well).

Polyglot Programming

My first professional work as a software developer was writing Clipper code. Clipper was a compiler for dBASE code with object-oriented extensions. This was in the days of DOS, and the entire application was written in a single language. We didn't even use SQL. Instead, the data storage was shared DBF files on a new concept, the LAN (I remember reading a PC-Magazine of that era declaring that the current year was the "Year of the LAN").

We are entering a new era of software development. For most of our (short) history, we've primarily written code in a single language. Of course, there are exceptions: most applications now are written with both a general purpose language and SQL. Now, increasingly, we're expanding our horizons. More and more, applications are written with Ajax frameworks (i.e., JavaScript). If you consider the embedded languages we use, it's even broader: XML is used as an embedded configuration language widely in both the Java and .NET worlds.

But I'm beginning to see a time where even the core language (the one that gets translated to byte code) will cease its monoculture. Pretty much any computer you buy has multiple processors in it, so we're going to have to get better writing threading code. Yet, as anyone who has read Java Concurrency in Practice by Brian Goetz (an exceptional book, by the way), writing good multi-threading code is hard. Very hard. So why bother? Why not use a language that handles multiple threads more gracefully? Like a functional language? Functional languages eliminate side effects on variables, making it easier to write thread-safe code. Haskell is such a language, and implementations exist for both Java (Jaskell) and .NET (Haskell.net). Need a nice web-based user interface? Why not use Ruby on Rails via JRuby (which now support RoR).

Applications of the future will take advantage of the polyglot nature of the language world. We have 2 primary platforms for "enterprise" development: .NET and Java. There are now lots of languages that target those platforms. We should embrace this idea. While it will make some chores more difficult (like debugging), it makes others trivially easy (or at least easier). It's all about choosing the right tool for the job and leveraging it correctly. Pervasive testing helps the debugging problem (adamant test-driven development folks spend much less time in the debugger). SQL, Ajax, and XML are just the beginning. Increasingly, as I've written before, we're going to start adding domain specific languages. The times of writing an application in a single general purpose language is over. Polyglot programming is a subject I'm going to speak about a lot next year. Stay tuned...