Improving Agile Communication using Old Tools

By popular demand, I'm blogging about a communication tool we're using on our current project. I've discussed this in my Productive Programmer talk at No Fluff, Just Stuff, and I've answered the Expert Panel question of "What is your latest favorite productivity tool" with this answer. Several people have asked me follow-on questions, so I thought I'd blog about it.

One of the difficulties in distributed agile development is keeping the communication link strong between the geographically (and time zone) separated teams. We are trying hard on our current project but still fall well short of the ideal. We do have some bright spots, though. The primary communication medium between the developers is a wiki we set up for the project. For a while, we attempted to type in really comprehensive summaries of each day's development work. However, we eventually realized that we were duplicating effort: we already put detailed comments for our check-ins to Subversion. So, we had one of our temporary resources cook up the following little developer shim.

He created a tool called SVN2WIKI. It uses the SVN post-commit hook to harvest the comment of the code just checked in. It then posts those comments to the Wiki, creating a dated page if one doesn't exist or adding to the page already there if it does. The Wiki we're using (Instiki) offers an RSS feed for all changed pages. So, we installed an RSS Reader (RssBandit) on the developer workstations. Now, when a developer sits down, he or she can get an up-to-the-minute summary of all the stuff that has happened to the code base since the last time he or she looked. Because it's an RSS reader, it keeps track of what you've already read. This is a great way to keep up to date at a really detailed level for what is happening to the code base.

This hasn't eliminated the need to create daily summary pages, but these can be much more terse, and focus on outstanding questions across the ocean. The Wiki contains a living history of the project, told one check-in at a time. For those who say that agile projects don't keep documentation, the Wiki on our project is a living, breathing history of the project at a really detailed level.

Our SVN2WIKI tool is a good example of piecing together a bunch of old and common technologies (SVN, Instiki, RSS) to create a great time saver for developers while improving the toughest part of our project.

The Ajax Experience Recap

I just finished speaking at The First (but certainly not the last) Ajax Experience, in San Francisco. It was held in the beautiful St. Francis hotel in downtown San Francisco, and it had the who's who of the Ajax world there. Ben Galbraith and Dion Almaer, the creators and maintainers of the Ajaxian web site, along with Jay Zimmerman of No Fluff, Just Stuff fame, put on a first-class conference. It was an interesting conference in that Ajax doesn't exist in a vacuum: it must be hosted on top of some other technology. I told one of my friends that it was like a condiments conference: you can't really have Ajax without some medium to present it upon. In any case, it was interesting to see such a diverse crowd rub elbows and get along so well. At one of the expert panels, we had the Lead Program Manager on the IE7 team sitting next to the creator of JavaScript. On another panel, the evangelist for the Microsoft Atlas framework sat next to the creator of Dojo (and 2 seats down from me). I represented pretty much the entire testing track there, showing a packed room how to use Selenium to test Ajax applications.

Because Ajax is at once broad (represented by the number of frameworks) but diverse (because it can be applied to just about any underlying web technology), I wondered if this conference would be a success. I can safely say that it was a resounding success, and it's going to happen again in the fall on the East coast. Kudos to Ben, Dion, and Jay for a great experience.

Buy 2, In Case You Lose the First

The No Fluff, Just Stuff anthology (edited by yours truly) is now orderable (they have gone to the printer, meaning that you can pre-order them from Pragmatic Press or get the PDF version right now). Check out the book page on the Prag's site to see it, order it, and fetishize it. I suggest that you buy at least 2, in case you lose one. And, nothing say lovin' to your spouse like an anthology of technical articles. Great wedding gifts, too.

Spreading the DSL Virus

Everywhere I go now (in a technical context anyway), I'm associated with the idea of Domain Specific Languages. At the No Fluff, Just Stuff expert panel this last weekend in Denver, my friend Scott Davis introduced me (we each introduced the member of the panel sitting on our right), and mostly what he said about me can be paraphrased as "he's the Typhoid Mary of DSL's". When I mentioned DSL's in answering a "Why is Ruby cool?" question, Ted Neward (the moderator) jokingly told me to not talk about it anymore.

But it's spreading further afield. I was at the Microsoft Technology Summit last week, and asked a DSL related question of Don Box when he was giving an Indigo talk. Afterwards, I chatted with him for a while about DSL's. Apparently, I got his attention. This week, he posted a blog entry looking for me to explain what the hell it was that I was talking about at MTS06. His blog entry and my reply is here. I pointed him to a great blog entry from my co-worker Jay Fields to illustrate to Don the power of this technique (found here).

As my regular reader(s) may know, I'm currently working on a book on DSLs for Pragmatic Press. The author team of Joe O'Brien, Jeremy Stell-Smith, Zak Tamsen, and myself are working hard to spread this virus far and wide.

Eating Sacred Hamburger

Software development cults tend to create sacred cows: habits and idioms that might have meant something at one time but only remain as baggage now. I tend to like to kill sacred cows and grill them up, with some nice lettuce, tomato, and a sesame seed bun. On my current project, we're actively killing some sacred cows.

Here are a couple of examples. Thankfully, Hungarian Notation has mostly been banished, except for one lingering, annoying location in the .NET world: the stupid "I" preface on interfaces. In fact, if you understand how interfaces should be used, this is exactly the opposite of what you want. In our application, every important semantic type is represented by an interface. Using interfaces like this makes it easier to do a whole host of things, including mocking out complex dependencies for testing. Why would you destroy the most important names in your application with Hungarian Notation telling you it's an interface? Ironically enough, that your semantic type is an interface is an implementation detail -- exactly the kind of detail you want to keep out of interfaces. I suspect this nasty habit developed in the .NET world because interfaces first came to the Microsoft world as COM (or, back when it started, OLE). It's a stupid cow now, and should be slaughtered.

Another sacred cow we're gleefully grilling up is the rule that all method names must use camel case. We're using this standard convention in our code, but have started using underscores for our test method names. Test methods tend to be long and descriptive, and it's hard to read long camel case names. Consider this test name:

[Test]
public void VerifyEndToEndSecurityConnectivityToInfrastructure()

vs. this version:

[Test]
public void Verify_end_to_end_security_connectivity_to_infrastructure()

Which of these is easier to read? The standard in .NET says that you use camel case, which we do...except in situations where it actually hampers productivity. If a cow gets in my way and slows me down, it's a goner.

In the book Pragmatic Programmer, Dave Thomas and Andy Hunt admonish developers to learn a new programing language every year. Seeing new ways of doing common tasks and learning new idioms is the best defense against sacred cows. Learning new languages helps you focus on how and why things work the way they do, divorced from syntax.

Coming Soon...The Ajax Experience

Jay, the creator of No Fluff, Just Stuff, has started conducting single-topic, destination conferences. The first was last year, The Spring Experience, where he brought together the entire Spring universe in Florida for 3 days.


This year, he's doing it again with The Ajax Experience. This amazing show takes place in San Franciso, May 10 - 12th (the week before JavaOne). It features the entire Who's Who of Ajax luminaries (and some dim lights, like me). I'm going to talk about testing Ajax applications using Selenium. And that's no coincidence. Jay has tried to get the creators of each of the parts of the Ajax world together, and I'm talking about Selenium because it was created by ThoughtWorks. Check out the web site and come to San Francisco. It should be an amazing 3 days.

Walking on the Wrong Side of the Street

The first time I ever went to Sydney, Australia, I couldn't get in sidewalk sync. It seemed like every time I walked down the sidewalk, I was walking head-long into groups of people. It was almost like I was swimming upstream. Then it dawned on me: these folks are used to driving on the left-hand side of the road, so they tend to walk on the left-hand side of the sidewalk too. Suddenly, it made sense, and my sidewalking skills improved overnight.

The same thing occurred to me this morning while I was walking from my hotel to the offices in ThoughtWorks India, and I noticed that everyone here (also being a former British colony) walks and drives on the left-hand side. Which side you tend towards when walking is one of those intrinsic, automatic things that you don't even realize is part of your cultural literacy until you go somewhere where it's the opposite.

The same kind of automatic response happens when developing software. I span the Java and .NET worlds, and I think it's interesting to see the kinds of cultural ticks that programmers from specific platforms develop. For example, in the Java world, you build frameworks for everything. In the .NET world, you organize things around the limitations of namespaces and solution files in Visual Studio, because it's the only real choice when it comes to IDEs. I have an advantage because I live part time in both worlds, so I try to spot cultural eccentricities whenever I sense myself walking on the wrong side of the street. Some things make sense in both cultures (like unit testing), while others are little more than arbitrary cultural baggage.

Dynamic Typing in the Strangest Places

One of my favorite things in college was the accidental synergy that happened between the collection of classes taken in a single quarter. Sure, compiler theory and automata match one another, but it's even more interesting when a history and computer science class find ways to complement one another. I get some of the same type of cross-pollination of ideas when speaking at conferences -- some of the topics end up complementing each other in odd ways.

It happened recently in St. Louis at No Fluff, Just Stuff. Part of the weekend, I was talking about how document centric messaging in SOA avoids endpoint versioning headaches. Later in the weekend, I was talking about the flexibility afforded by dynamic languages and their loose typing. Then, it occurred to me: SOA and the document centric approach is really just another version of dynamic or loose typing. If you free the plumbing from having to know what types you are passing (in this case, just a blob of XML), you create a more flexible system, able to withstand changes more gracefully. Just like with dynamic languages.

I've been sauteing in this idea for a while: we are building the same kind of application right now on the project I'm on. And, even though it's written in .NET 2, we take advantage of loose typing in the transport layer, which ultimately makes for a more robust application. How do we handle catching version conflicts? The way you should handle all such situations: unit testing. Loose typing + unit testing provides the same security you get with strongly typed languages but much more flexibility

Finally, An Accurate Representation of My Graphical Skills

During a lunchtime conversation today, because of the specific context, I came up with a great quote about my abilities as a graphical designer:

Graphical design is like pornography: I know it when I see it, I don't want to participate in it, and you don't want to see me try it either.

'Nuff said.

A Dearth of Fluff, Significant Stuff

As my regular reader(s?) must have noticed, I've been very quiet for a while. No, I haven't given up pontificating; I've been working diligently on a new year of No Fluff, Just Stuff presentations. Every year, I cull some of my old talks from the herd and send them to the virtual glue factory and add some new, spry colts to the fold. This year, I've added about 4 new talks and killed the same number, and I've been spending the last couple of months getting them in shape. This last weekend was the debut of a couple of them (along with 5 of my existing talks).

No Fluff, Just Stuff Gateway Software Symposium occurred in St. Louis over the weekend. I gave a total of 7 talks: clean Up Your Code, Advanced Enterprise Debugging Techniques, SOA & ESB: The Future of Distributed Computing or the Return of the Son of CORBA?, Pragmatic XP, the new Testing with Selenium, the also new The Productive Programmer, and finally Language-oriented Programming and Language Workbenches. Whew! It was a long weekend, but the new talks turned out well (only requiring minor tweaks, not major overhauls). And, someone was nice enough to blog about one of my talks (always good to get feedback).

It's great to get back to No Fluff. Many of the speakers are good friends, so it's good to see them again. One of the speakers made an excellent observation that also applies to me: I have more friends that travel the country every weekend than I do at home! It's good to be back in the saddle again.

Dependency Injection in Geronimo, Part 2

As surely as Spring follows winter, the 2nd part of my depenency injection article on DeveloperWorks is now live. This version builds on the "raw" topic of dependency injection in the 1st part and shows how it applies to Geronimo. Geronimo has a very interesting architecture, and will surprise some people who think that "dependency injection" == "Spring".

My Last Borland Post Ever (I Promise!)

Those of you who follow my blog know that I post an inordinate amount of material about Borland. I have a long-standing love for Borland: my first book was on Delphi (Developing with Delphi: Object-oriented Techniques) and my second was on JBuilder (JBuilder 3 Unleashed). I learned about real software development using Borland tools. When I bought my first computer, I bought just 2 pieces of software: DOS 3.3 and Turbo Pascal 5. And I didn't need any other software for almost a year.

Borland has perpetual financial and directional problems over the years. But, like loyal fans of Saturday Night Live, most of us stuck around even when it sucked (Inprise, anyone?)

Now, though, Borland has taken the last fatal step towards irrelevance: they are in the process of divesting their entire IDE division (check out this eWeek article). Yes, that's right: the company that brought us Turbo Pascal, Turbo C, Turbo Prolog (OK, maybe we didn't need that one), Delphi, and JBuilder will no longer sell a single compiler. I wonder what Anders thinks about this (or if he even noticed).

Borland is reinventing itself as a strictly ALM (Application Lifecycle Management) company, selling tools that have awesome support for Big Design Up Front (BDUF) like CaliberRM, TogetherJ, and the Segue tools they just acquired. What a great day for Waterfall projects (I wonder if they would consider sponsoring the Waterfall 2006 conference)?

For those of us with an irrational (pun intended) love of Borland, this is indeed a dark day. RIP.

Continuous Integration Conference

An interesting (free!) conference is coming to Chicago in early April this year, an Open Space event on Continuous Integration and Automated Testing. Both of these subjects are dear to my heart, so I'm hoping to help get the word out about this conference. They organizers haven't set the date yet because they need to see how many people are interested before they will know how big a space to reserve.

Support CI and AT: contact Jeffrey Fredrick (jtf@agitar.com) or Paul Julius (pj@thoughtworks.com) through the Yahoo group groups.yahoo.com/group/citcon and sign up for the mailing list.


Automation and Testing are Good Things!

Dependency Injection in Geronimo Part 1

IBM DeveloperWorks has posted the first of a two-part series on dependency injection in the Geronimo J2EE container. This article focuses on the mechanisms of DI and uses PicoContainer as the container. I did this to divorce the idea of DI from the particular implementation in Geronimo. One of the problems I see in concepts like DI revolves around how you learn it: the implementation from which you learn influences your perception of if forever. Many developers think that DI and the way Spring works are the same thing. By using the lightest weight container I could find (PicoContainer), I hope to show DI in as context-free an environment as possible. The next part of the article takes the concepts and injects (pun intended) them in to Geronimo.

SOA Under a Giant Arch

I'm flying to St. Louis tonight to speak at the Gateway JUG. I'm doing my SOA: The Future of Distributed Computing or the Return of the Son of CORBA? talk, helping to promote the upcoming No Fluff, Just Stuff Gateway Software Symposium. Because there is so much sound and fury with so little substance in most SOA discussions, I'm trying to take a pragmatic approach to building SOA, which includes the (what I consider essential) focus on agile development techniques. I feel like I can offer some insight on this subject because I've lived through a lot of distributed computing initiatives and seen a lot of failures. This talk is about how to achieve some of the lofty goals espoused by SOA advocates with a healthy dose of skepticism.

D-Cubed

I recently read about a most interesting innovation in software development methodology I've heard in a while: Defect Driven Design (D3, pronounced "D Cubed"). This methodology addresses the weak points of most other development methodologies.

Working in D3 is very simple. At the start of the project, you announce that all development is complete and the application is ready for user acceptance testing. The first thing the user will say is "Hey, I thought there was supposed to be an icon on the desktop to launch the application". That's our first defect. We implement code to put an icon on the desktop and announce again that we are done. The user clicks on the icon and nothing happens: "Where is the application?" That's our next defect. You can imagine what the rest of the development rhythm.

The brilliance in this methodology lies in the estimation power. We can estimate with absolute accuracy: 0 days. The entire lifecycle lies in maintenance, which is more realistic because useful software is never actually complete.

Conference in a Castle

It's already time for the first conference of the year. I think this is the earliest start I've ever had. I'm speaking this weekend at the Javagruppen Arskonference conference, conducted in the Hindsgavl castle in Denmark. I heard about this conference from colleagues last year -- they had a blast, so I'm looking forward to it. I'm doing 2 talks, both on Domain Specific Languages (Theory and Practice). This will be my first trip to Denmark so, given my love of traveling to new places, should prove to be a fun trip.

Can I Get Some Rails at this Boutique?

At the Newark No Fluff, Just Stuff show last year, someone from Java Boutique interviewed speakers during the course of the symposium. It was the end of the day and he was still missing some of the speakers, so he decided he would just interview us together. The hot topic of the conference was Ruby on Rails. Thus, myself and two of the people I respect most, Stuart Halloway and Justin Gehtland (from Relevance), talked for about 20 minutes about Ruby, Rails, and Java. The interview is just now out at the Java Boutique web site. It's sometimes interesting what you say when you are tired, hungry, and sitting next to 2 brilliant people. Upon reflection, I like the bit about the bicycle (which I made up on the spot and forgot until I re-read this interview).

Pervasive Search

One of my good friends has a great expression when he sees some really cool technology goodie that we'll get "Real Soon Now": "I want to live there!".

One of the touted features of the next version of Windows is pervasive search, or search at the operating system level. I was skeptical of the value of this feature. After all, we now have Google Desktop, right? I can search and find documents pretty quickly now.

However, what's missing from Google Desktop is the "pervasive" part. I didn't fully appreciate this missing element until I started using the Mac, because Mac OS X now has Spotlight, Apple's version of pervasive search. Spotlight has a little icon on the menubar to let you search for stuff, just like Google search. But the pervasive part is more useful to me. Check out the standard Mac save dialog:



Because search is embedded at the OS level, I can use search to save files instead of navigating my document hierarchy. When I save a file on the Mac now, I search for the folder in which I know it belongs, then I name the file. It's not like I fear or don't understand hierarchies in a file system. But why bother doing all that navigation? I know where I want to put it, and the OS should be smart enough to let me tell it without all the ceremony. That's pervasive search, and it has changed the way I use my computer. Now, I can't wait until my work OS catches up to what is one of my favorite features of my favorite OS.

Not that Spotlight is perfect yet. It's annoyingly slow, and it sometimes yields some false positives. That irritates me. But, the benefit outweighs the annoyance factor by a lot. And I doubt that the first version of pervasive search in Windows will work perfectly either. I view this as a "I want to live there" feature: I can't wait until I can stop navigating hierarchies most of the time.

Ok vs. Silence

The very origins of DOS and Windows tells you something about the way it works now. I remember reading that in the original piece of software that Microsoft was hired to write, BASIC for the original IBM PC, one of the most difficult tasks was to get the interpreter to fit into the memory they had available in the machine's ROM. We're talking very primitive hardware here, and quite the engineering feat to work within those constraints.

One of their decisions speaks volumes about the philosophy that suffuses much of Microsoft software today. Because memory was so tight, they couldn't afford the number of bytes to print the traditional "READY>" on the screen, so they chose "Ok>" instead. If any of you remember using the BASIC built-in to the original PC, you'll remember that "Ok>" prompt.

Why say anything at all? If resources were tight, why not just provide a simple prompt when everything is OK? Like ">"? This is exactly what the Unix guys did when they needed to be frugal with resources -- they invented the idea that "no news is good news".

Take this simple distinction, "Ok" vs. "Silence", and multiply it by millions of lines of code and decades of development. What you end up with is the most annoyingly chatty software you can imagine, Windows and Office. They constantly pester me about things I don't care about ("You have un-used icons on your desktop", "You're network cable is unplugged", "Let me go harvest clip-art from the Internet for you", etc.). An alternative is Mac OS X, which is sublimely quiet most of the time, and of course command-line Unix which is positively mute (until it needs to tell you something that you really need to know).

Obviously, chatty software annoys me (I've blogged about shortcuts to turn off some of the annoying balloons in Windows before). But I had never thought about why it is that way until I remembered that, when given the choice between silence and verbosity, Bill and Paul chose the latter.

Bearable Moments

Friends and family, when they discover that I've written several technical books, ask me if I ever plan to write a novel. My stock response to that is "No! -- Writing a novel would be much more difficult for me, because in technical writing you just describe stuff, whereas in a novel, you have to create an entire internally consistent universe from whole cloth.".

Which makes Christopher Judd's Bearable Moments such a remarkable achievement. I've known Chris for years, and he's written a couple of fine technical books (Pro Eclipse JST: Plug-ins for J2EE Development and Enterprise Java Development on a Budget: Leveraging Java Open Source Technologies. Now, he's written his first children's book, Bearable Moments. One of the most daunting tasks facing any writer (no matter what the genre) is understanding and empathizing with the intended audience. To me, that makes writing a children's book one of the toughest jobs a writer can face. Hat's off to Chris -- I hope his venture into non-technical publishing garners him the accolades he deserves.

Is Struts Over?

At ApacheCon last week, I finally met some developers for whom I have great respect: Ted Husted, Craig McClanahan, and one of the original authors of WebWork (unfortunately, I didn't get his name). It was nice to finally meet these guys, even if it was during a train wreck. About the wreck in a second, but first why I can talk about said wreck. I have no small insight into the web framework world -- I did after all write a book just over 2 years ago (Art of Java Web Development) featuring Struts (the King of the Castle at that time), Tapestry, and WebWork. I think my crystal ball wasn't bad for those 3 particular frameworks. I've been giving conference talks on framework comparisons since the book came out, as well as conducting some Birds of a Feather sessions on web frameworks. All this credentializes me in the web framework space.

I bring this up for 2 reasons. First, I think the original Struts succeeded in no small part because it was simple. If you knew how request-response worked, and you knew a few design patterns, you could figure out most of Struts in about a day. Meanwhile, the competition (Tapestry, Turbine, WebWork) were a bit more complex. This is back in the day when people weren't even sure you needed a web framework -- most people were just rolling their own. Along came Struts, which managed to hit the sweet spot of solving some problems without being too big or complex. If you spend some time with them, I think that WebWork and Tapestry are better conceived frameworks (with totally opposite approaches). Note that this was a million years before Ruby on Rails was even a glint in DHH's eyes.

The second reason I bring this up was because I found myself in a Birds of a Feather session on Struts at ApacheCon. And my distinct impression was that of moving deck chairs on the Titanic. The big news of late, of course, is the merging of WebWork into Struts. But, at the same time, the Shale extension of Struts is rolling right along. There was a great deal of discussion about how to manage to reconcile these two fundamentally different paths (action framework vs. component framework). And, unfortunately, all these efforts apparently will appear under the Struts name.

I understand the software geek drive to always reach higher and further. But I think you also need objective perspective about what you've created. Based on my observations, the Struts team has completely lost that perspective. My solution? Keep Struts right where it is, a nice simple web framework with very low barrier to entry. Go ahead and enhance WebWork (and call it WebWork), and go ahead and work on Shale (and call it Shale). Trying to make Struts into an integration platform with lots of complex moving parts kills the one thing that Struts truly has going for it: simplicity in the face of ever growing complexity in the web framework space. For the polar opposite of simplicity, see Faces, JavaServer.

Ruby for Java Developers at ApacheCon

About 6 months ago, I submitted several abstracts to ApacheCon, and two were chosen. The first was cross-language Regular Expressions, which is no big surprise, given my history with that topic. The other selection surprised me: Ruby for Java Developers. This is a talk I have prepared for No Fluff, Just Stuff, but never had a chance to deliver it (you don't get to do Ruby talks when at the same conference as Dave Thomas, nor would I want to). During the interim, Ruby has gathered even more steam, so I was anxious to give this talk and see what kind of interest was present. I talked to several people over lunch about Ruby, and everyone I talked to at the conference said they were interested my talk.

The appointed time arrived, and I wasn't disappointed. They booked it in the large keynote room, and I had over 100 people for the talk. I had to rush a bit because I had too much material (I'm sure those of you who know me will be shocked by that), but the talk turned out really well. I ran up to and slightly into the afternoon coffee break, so I made the offer for people to stick around and ask questions after the talk. I had about 10 people come up and ask me about various aspects of Ruby, and everyone was interested and engaged.

I've been positioning myself both within ThoughtWorks and externally as a pragmatist on Ruby. I really like Ruby, but I'm not ready to sell the farm on more mainstream languages yet. Ruby has tremendous potential, but there are still hard problems to be solved in Ruby before it can storm the castle walls of Java and .NET. I fully believe that those problems will fall (and I think ThoughtWorks will solve many of them, just as we solved problems in Java and .NET). Of all the candidates for "Next Big Thing", Ruby is the clear, ahead of the pack contender.

Stalking Dr. Hawking

I don't really understand the weird fetishization of celebrity in the US. It seems that everyone wants to meet someone famous and get a piece of them. What's up with autographs? What does it mean that you got someone you admire to sign a piece of paper?

I understand the desire to meet and talk to the people I admire. But, going up to a famous person and being able to enter a real conversation with them is absolutely impossible. Because nuts stalk famous people, they must always be on their guard.

Because I feel this way, I have never approached anyone to shake their hand or get an autograph -- it's utterly meaningless. Besides, there are very few people in the world whos stature I would consider worthy of an autograph. I almost walked over one of them a couple of weeks ago.

During my last trip to San Francisco, my friend Terry and I went to Beethoven's opera Fidelio. Terry was calling home, so I was walking around the beautiful opera house. As I rounded a corner, I came upon a really elaborate wheel chair. I thought to myself "Wow, that's a really elaborate Stehen-Hawking-style wheel chair". Then I walked around the front and nearly bumped into...Stephen Hawking! I remembered reading that he was in town lecturing in San Jose while I was in San Francisco. Of course, even if I wanted to get something silly like an autograph, his advanced state of Lou Gerhig's disease would make it cumbersome. As much as I'm not star struck, it was a little amazing to be so close to such a great man. If ever there was someone worthy of adoration, I would vote for him long before the pop star of the week. I hope he enjoyed the opera!

A Year at the No Fluff Round Table

The last No Fluff, Just Stuff show of the year just wrapped up a few weeks ago in Denver. My travel schedule has been pretty brutal lately (in fact, I spent the week between No Fluff Dallas and No Fluff Denver at another conference in San Francisco), so in a way I'm glad that my weekend travel is winding down for the year (just one more conference for the rest of the year, ApacheCon). I was surprised, though, at how much I dreaded the end of the show in Denver. I've made real friends with speakers on the tour this year, and the propect of not seeing any of them for 3 or 4 months affected me more than I thought it would. When you do a series like this, you end up taking for granted many of the less obvious features, like when you will see your friends again. Then, the series is over for the year, and there is no upcoming event.

This has been a great year for me at No Fluff. I ended up doing 14 shows this year, several more than I had planned, but I'm certainly glad I did. I've blogged about the extraordinary level of attendees before, and they help make the weekend fly by. But the other thing that drives me from my home for a dozen+ weekends a year is the chance to get to hang out with the other speakers.

Back in the 1920's, a group of writers, actors, and other artists started gathering a few times a week at the Algonquin hotel restaurant. This group included Dorothy Parker and Harpo Marx, among others (for a great movie that depicts this group and era, check out Mrs. Parker and the Vicious Circle). According to legend, the Algonquin Round table discussions were the wittiest in history because they had gathered the quickest wit in New York at that time, which was the best in the world. Here are a few samples:

Robert Sherwood, reviewing cowboy hero Tom Mix: "They say he rides as if he’s part of the horse, but they don’t say which part."

Dorothy Parker: "That woman speaks eighteen languages and can’t say ‘no’ in any of them."

George S. Kaufman: Once when asked by a press agent, "How do I get my leading lady’s name into your newspaper?" Kaufman replied, "Shoot her."

No Fluff has created a geek version of this same phenomenom: the speaker's dinner. On Saturday night, the speakers go somewhere and eat, and every one of those gatherings ends up being the most fascinating coversation you can imagine. All these brilliant guys, gathered to talk about what they've been thinking about all week that they can't discuss with their spouse. I've had more revelations over food during the last year than I probably had my entire life leading up to this year. So, while I'm glad to spend some time at home, I can't wait for the next gathering of the No Fluff Round Table next year -- I'm sure that we will all have several months worth of pent-up discussion just waiting.

One of the Cool Kids Now

After (literally) years of anticipation, it has finally happened: I'm one of the cool kids. I have a Mac. Yes, I bought a PowerBook a couple of weeks ago, in anticipation of the new book project I'm starting. Here is a picture of my new baby:



I almost did this about 4 months ago, until Apple announced the Intel partnership. That froze my decision, thinking that I could hold out until the Intel PowerBooks arrived. But, because of this project (which I will talk about more in a future post), I needed it sooner rather than later.


My finger was literally hovering over the green "Buy" button on the Apple web site, but my spidey sense told me not to click yet. The very next morning, I went to the site and was greeted with the "New Powerbooks" banner headline. Because I waited the extra day, I got the video card upgrade for free, a higher resolution display, and generally cheaper machine for the same configuration. I saved enough to pay for the extra 1 GB of memory from Crucial.


I've spent the last couple of weeks getting used to the Mac, and it's a joy. Unfortunately, I now travel with 2 laptops (the ThoughtWorks issued Dell Latitude 610, which I need for work, particularly .NET development) and the PowerBook for everything else. But, it's a small price to pay to hold my head up high when I'm hanging out with the other No Fluff, Just Stuff speakers (mostly Mac guys because they can). When I write Java, I'm living the dream: using IntelliJ on a PowerBook. At least for the short term, my hedonic adaptation is sated.

In Praise of JBoss at Work

I just finished Scott Davis and Tom Mars new book, JBoss at Work. He and his co-author do a brilliant job of taking a dauntingly large topic, an application server, and writing an engaging book about it. I particularly like their approach, which is very pragmatic: they take a web application that consists of static pages and gradually add more dynamic behavior, one step at a time. I think this is a particularly effective way of introducing a topic (I did the same thing with web frameworks in Art of Java Web Development because it addresses the whys as well as the hows).

My only complaint is one that Scott also laments: lack of testing code. But, I understand that the book would be much larger if they had incorporated testing. In that regard, they did the right thing: the book is about JBoss, not about testing in the J2EE space (a topic worthy of a large number of books all by itself). Kudos to Scott and Tom for a great book.

Art in San Francisco

I've blogged a lot about Borland International, to the point where even I'm sick of it! I've written about them so much because I had such a close relationship with the company in years past. But, as I've written, time has passed them by. Last week, I spoke at what is sure to be my last Borland Developer's Conference in San Francisco. I was there with a good friend (who was also attending the conference). I spoke at several sessions, but when not at the conference, we took advantage of what the city had to offer.

Monday we planned for the rest of the week. Then, on Tuesday, we went to a concert at The Fillmore (mostly just to see the venue). We saw Missy Higgins and Liz Phair, both of which were entertaining. Wednesday, we went to a matinee of the Tennessee Williams play Cat on a Hot Tin Roof. Wednesday night, opera at San Francisco opera (Fidelio, Beethoven's only opera). On Thursday, we went to SF Museum of Modern Art (one of my favorite museums), then went to dinner with friends and went to a heavy metal concert at Slim's (Fu Manchu).

During the week, I also gave 4 talks and a 4 hour pre-conference tutorial, and I got some work done as well. Mostly what we didn't do was attend any of the other sessions! All in all, a great conference week.

No Fluff, Just Stuff Does .NET

About 18 months ago, I participated in an event that changed my life, although I didn't quite grasp the significance at the time: I spoke at my first No Fluff, Just Stuff conference in Austin, TX. My publisher, Manning, put me in touch with Jay Zimmerman, and we played phone tag for a few weeks. When I finally talked to him about speaking at that first show, he kept going on and on about "this show is more advanced than other conferences" and "I'm really dedicated to keep the quality sky high". Basically, the stuff I've heard over and over again from other conference organizers. I was no spring chicken at conference speaking. I had already presented more than 100 conference sessions all over the world. So, I thought "Yada, yada, more of the 'we're better than everyone else' blather."

But a funny thing happened in Austin: he was right! Suddenly, my ace game was barely adequate. I distinctly remember telling co-workers when I returned that I felt like a kid eating at the adult's table. Jay had (and has) managed to create an extraordinary gathering in every city he visits. I have perspective on this because I've been to lots of conferences. Maybe it's the weekend seclusion, or the longer than average sessions, or the high level of discourse in the session which spills into the hallways, the meals, and to everyone you meet. It's all those things, with one more keystone ingredient: the speakers. I am honored and humbled to be considered a part of this extraordinary group of individuals: the most brilliant minds in the industry, genuinely personable, gregarious, funny, and centered. Jay has created a work of genius, gathering this group to talk about technology 27 weekends a year.

Until now, unless you were a technology switch hitter, you had to be in the Java (or, increasingly, Ruby) crowd to even know that No Fluff, Just Stuff existed. Now, Jay is expanding this phenomenon to the .NET world. December 2nd begins a new era for .NET developers: you get your very own No Fluff, Just Stuff. Ted Neward is running this show, and it is his considerable burden to re-create the pure magic of No Fluff, Just Stuff in the .NET space. If anyone can pull it off, he can. A new group of speakers, a new set of cities, and a new chance to create a community revolving around the most unlikely of campfires: a computer platform. There are a few of us participating in both worlds (myself, Ted, Glenn Vanderburg, Stuart Halloway, and a few others). It will be our job to set the tone for the new speakers to create the same but different ambiance for a new crowd.

Every so often, an event happens that you simply cannot miss, and, for .NET developers, this is the Beatles in Shea Stadium, Elvis on Ed Sullivan, and Johnny Carson's last Tonight Show. The premiere. One weekend only. Denver, December 2-4, 2005. The first of many, many No Fluff, Just Stuff.NET shows. You have to see it to believe it.

Technology Snake Oil 7: Demoware

I think one of the reasons that RAD tools (including ASP.NET) made significant inroads was the demoability of their development. RAD tools allow you to click and drag your way to poorly designed applications with remarkable speed. Managers who go to product launches see lots of 15 minute demonstrations of building an enterprise application that talks to a database and allows pull-down lists in the columns of the grid, all built while the speaker is talking. I know because, in a former life, I used to do some of these demos on behalf of a vendor (and I'm still repenting).

Of course, every real developer knows that you can't do real development like that. In fact, most developers now (I hope, at least) know to create layered, modular applications so that they are maintainable, updateable, and a bunch of other "-ables". But this sea change hasn't permeated most managers yet. They still purchase development tools (on behalf of developers) based on 15 minute technology demonstrations. I firmly believe this is one of the reasons Sun created Java Studio Creator for JavaServer Faces. They were getting killed in demoware sessions against Microsoft's ASP.NET story. Now, Sun can compete with Microsoft on creating useless toy applications in front of a crowd. And they say there's no such thing as progress!
This hurts development on several levels. Real developers are frustrated because their managers develop unrealistic expectations for the rate of development. Managers are frustrated because they can't figure out what their developers are doing for the weeks and weeks it takes them to build what looks on the surface like the toy application they saw someone build in front of them. And both groups are irritated at each other.

I'm not against productivity tools (I'm not a "use-linux-and-Emacs-for-everything-everyone-else-is-a-wimp" kind of Stallman-esque developer. I use IDE's and appropriate tools, including some of the aforementioned RAD tools, although not in the manner suggested above. In fact, I have a tool fetish that I must constantly fight (you know, Emacs is pretty darn powerful in a lot of circumstances). I am against vendors who try to seduce managers and other non-techies with shiny objects that don't really deliver the promise of the snake oil they sell.

Technology Snake Oil Part 6: Drowning in Tools

In my last Technology Snake Oil posting (Part 5: The Integration Myth), I talked about the more and more comprehensive IDE's and the bundling together of more and more tools. I think that Microsoft Office and Visual Studio point to a disturbing, Borg-like trend. It doesn’t matter if none of the tools is the very best at what it does, as long as it works nicely with all the other tools in the suite.

The problem we have in the development world is that we are drowning in tools. The “bit rot” problem in Windows is well known. The more software you install, the more likely there will be conflicts between components, the slower it gets, and the flakiness level rises. I reached an interesting milestone recently. I had the opportunity to build my development laptop completely from scratch (no ghost images, everything installed in pristine state from CD's). Anticipating this momentous occasion, I compiled a list of all the tools that I thought I couldn't live without. Many of these tools are very special purpose (like WinMerge), many of them are open source, but they are all tools that I use, maybe not daily, but at least sometimes. Once I got everything installed, I started getting the kind of flaky behavior symptomatic of a bit-rotted Windows machine. I had reached a milestone: my basic working set is incompatible with Windows.

This led me to pare way down on the tools I use. Every tool has to defend its life, and make the cut to survive. I gave up some stand-alone editors (I have a text editor fetish, and formerly had a bunch of them, each for one or two things they did really well). Most of those chores have moved over to Emacs now. OK, and Notepadd++. And Crimson Editor. But that's it! I promise! I’ve been actively trying to cut down my working set.

Developers love software, and tend to accumulate a lot of it. In the pathological case, developers can spend more time installing, uninstalling, and trying to get integrations working between tools that they have no time left for productive work. I have to fight this tendency in myself to try new tools, because each one represents a shiny new object that will, according to its web site, be faster, lighter, more aerodynamic, and brighter, a floor wax and a dessert topping. Using an over-worn analogy, we have an entire wood working shop filled with expensive, gasoline powered, multi-purpose saw/drill/lathe/turnip twaddlers.

Instead of monolithic tools, we need very cohesive, modular tools. The Unix guys got it exactly right – create simple command line tools that follow a few conventions (like all input and output it unadorned text). They created independent, cohesive modules of behavior. Once you understand how these modules work, you can chain them together to achieve what you want. They even built in integration tools, like xargs (which lets you massage the unadorned text output from one program into the expected format of another). Without question, someone who understands how these tools work is more productive (with fewer headaches) than someone struggling to use a behemoth like Software Delivery Optimization. Why are the command line tools better? You can script them in nice clean ways, and let the computer do work for you. One of the unfortunate trends with graphical environments is the dumbing down of power users. If you watch how power users in the Unix world work vs. typical power users in the Windows world, the Windows guys (on average) are working a lot harder, performing a lot more repetitive tasks. We need a woodworking shop filled with simple hand tools, not more electricity and kerosene. Throw yourself a life preserver; download cygwin today.

LOP Weekend

This last weekend was the No Fluff, Just Stuff Atlanta Symposium. Because he had to go back to Dallas, Dave Thomas wasn't available to do the keynote address on Friday night. So, Jay the conference organizer asked me to fill in, with a scaled down version of my Language Oriented Programming talk. I was already scheduled to do the two-part version of this talk (Part 1: Theory, Part 2: Practice) back to back on Sunday. This was turning out to be a LOP weekend! I took the theory portion of the talk and removed a lot of the hard-core technical details (no one at a keynote wants to see page after page of code, especially grammars for custom languages). The keynote went pretty well, with no major gaffes. The flow wasn't as good as I would have liked it (the talk at the time I gave it was almost 8 hours old, but it's a topic I've been talking about all year).

I was afraid that everyone would be sick of this topic by the time Sunday afternoon rolled around. However, I had a good group for both parts of the talk. Several people asked me during the day if it made sense to come to the second one if they didn't come to the first, and I assured them that it was OK. The first part of the talk was up against one of Keith Donald's Spring talks, which is tough competition this year at No Fluff. The first part of the talk replicates the material in the keynote, but at a much higher level of detail. The second part of the talk is designed to be more practical. I show some interaction with JetBrains Meta-Programming System, but mostly the 2nd part encourages discussion about the viability and future of LOP. We had a great discussion, including problem domains that match LOP early adoption and what developers are already doing in this space. One of the more active attendees works for a really, really big company here in Atlanta, and he stated that LOP is currently number 4 on their list of hot technology trends to watch (no, I didn't ask what the other 3 were). He was an evangelist within his company for this evolution, so that's why he was so involved in the discussions around it all weekend.

One of the best things about discussing a topic like LOP at No Fluff conferences is the number of people that you meet that are already doing this. The general level of the audience at No Fluff continues to amaze. For something new like LOP, No Fluff provides a valuable traveling road show to meet and greet the folks who represent islands of cutting edge technology (who generally are just looking for a kindred spirit for discussions). Last year, one of the attendees commented that the best thing about No Fluff is that he could talk about work and everyone around him knew what he was talking about!

Chattanooga Choo Choo

I'm traveling north to Chattanooga, TN, tonight to speak at the
Chattanooga Java Users Group meeting. This is interesting because the
trip from Atlanta to Chattanooga takes me back through my home town of
Dalton, GA. I was contacted a few months by an alumni from Dalton
Junior College (where I got my associates degree is physics) who
recognized me from an article or something and asked me to speak at
CJUG. So, instead of getting on a plane to speak at a JUG, I'm driving
for 2 hours.

This will be an interesting blast from the past for me. Chattanooga is
only about 20 miles north of Dalton, so I spent a lot of time there
growing up. One of my summer jobs was in Chattanooga. And, it gives me
a chance to stop by and see family on the way back. Today will be a
misty, rose colored memories kind of day for me. Oh, and then I have
to talk about JavaServer Faces! A harsh plummet back to reality!

Slashdotted!

A strange thing happened over the last couple of days. Without much fanfare (even the Developer Works guys didn't tell me), my article on the Developer Works site about the Ruby Developer's Toolkit for Eclipse was published. No big deal, I've had several articles published there. Then I started getting emails about it yesterday, some from people I hadn't talked to in a long time. Hmmmm, I guess Developer Works has more subscribers than I thought. Then, someone told me: the article has been Slashdotted! Wooo-hooo! My first Slashdotting. That's why everyone knew about it. It's kind of a geek rite of passage. Now, I just need to be Biled...

Ruby for Java Developers

Ruby for Java Developers

My article on the Ruby Developer's Kit has just been published by the IBM Developer Works site. The RDT is not a full-blown IDE for Ruby yet, but it does have excellent support for debugging Ruby code, which is a huge win for me. I've debugged some pretty hairy Ruby code in it (including code that does automation in Windows) and have been very happy.

See, I'm trying to find a way to bind the Java and Ruby communities together. Can't we all just get along?

Missing the Point

One more post from the Entwickler Conference, where the Borland faithful gather in Germany. I sat though the technical keynotes, and they preach two things: Rapid Application Development tools and Big Design Up Front with requirements gathering tools (CaliberRM) and UML (Together). I know a lot of vendors are still beating these horses, and Borland is no different. Delphi now includes a EJB-like framework for persistence and workflow called ECO, which makes heavy use of tooling and inheritance. It doesn't use any of the interesting techniques used widely in the Java world (like dependency injection). Looking at ECO gives me Java flashbacks from 3 or 4 years ago. Anyway, the big finale of the technical keynote (which showed that they have created very good products in their categories), David I (Borland evangelist) showed a video of a 5th grader using Delphi and ECO to build a Teachers -> Classes -> Grades application with persistent and a generated front end in 9 minutes. The obvious message: you can build simple things Really Fast with our tools. Or maybe it was "Build Crappy Software Faster!"

Is that the right message to send out to the world? Is raw developer productivity for mindlessly simple applications buying us anything? The only people impressed by this type of demo-ware are non-technical managers, who have budgets. "Wow, if a 9 year old can build an application in 9 minutes, just think our developers will be building our entire corporate infrastructure! We must buy this tool!". I've posted my thoughts on RAD before. It is disappointing to see a company with so many sharp people pushing 2 aspects of software development that I think counter productive.

Not everyone in Borland feels this way. I'm corresponding with several Borlanders about how they can support agility in their Application Lifecycle Management (ALM) tools. The tide is turning. I am not naive enough to think that they should just ditch their product base because of what is still just opinion. I just hate to see what I consider poisonous messages to developers and their managers.

Dexter

As I stated in my last post, I spent the last week at the Entwickler Conference with the Delphi crowd. One of the highlights of the conference was the technical keynote where they showed the next version of Delphi, code-named Dexter. First, a little background about Delphi. From version 1 thought 7, Delphi was written in itself. The IDE is an Object Pascal project, written using the tool itself (including the components available in the tool. This is nothing new, building a tool in itself, but it was an eloquent argument for the capabilities of the language and libraries. Starting in version 8, Borland re-wrote their IDE base, creating Galileo. Galileo was the base host IDE for both Delphi 8 and C#Builder, their competitor to Visual Studio. One of the key benefits of Delphi 1 through 7 disappeared overnight, because they had to start from scratch. Delphi 8 had a different look and a small sub-set of the capabilities of the version 7 IDE. It was slow, buggy, and had serious re-drawing issues (watching it try to launch an application caused so much flickering that it could induce seizures). This, by the way, was richly ironic to the JBuilder crowd, which had been suffering taunts about slowness and ugliness for years from the Delphi crowd. Flash forward a couple of years. C#Builder became a non-product, and was rolled into Delphi 2005, which hosted both languages. It was a little better but still only about 30% as capable of a really good IDE like IntelliJ.

This has changed somewhat with Dexter. I was pretty impressed with what I saw. As a development tool, it is approximately on par with Visual Studio now in all but stability (beta testers tell me it is still pretty scary). Microsoft has the luxury of beta testing VS for 2 years; Borland cannot afford even a fraction of that. Still, the environment looks pretty good. It finally has a reasonable number of refactorings available (Delphi 2005 had 4, and from the reaction of the Delphi faithful last year, you would have thought that Borland had invented cold fusion). In my estimation, it is about 70% of a real IDE now. It is still hosted on Galileo, but it has greatly improved over the last year or so. The same IDE supports both Win32 and .NET development and has all the Borland Secret Sauce components. The next release, due out mid-next year, will even support .NET 2.0. Still not compelling enough to get anyone to consider it as an alternative to Visual Studio for new C# development (unless you are deeply immersed in Borland's Application Lifecycle Management integration strategy) but at least it isn't an embarrassment now.

How Important is Syntax?

I spent the last week at Kool-aid central for Borland's Delphi RAD
development tool. I was speaking at the Entwickler Conference
("Entwickler" is German for "developer") in Frankfurt, talking about
Java and .NET. This conference is ostensibly a general developer's
conference, but Borland is one of the main sponsors and it has
traditionally been the European gathering place for Delphi developers.
The faithful only get one Delphi focused conference per major land
mass, so they all come. The Java and .NET guys can get information
anywhere. Probably 70% of the talks at this conference either focus on
Delphi or overlap significantly (for example, I did an "Updated
Design Patterns in .NET " in C#, but the material also applies to
Delphi.NET).

The interesting part of my trip were the discussions between sessions,
at dinner, and in the halls. Even though Delphi is a niche development
tool with a shrinking market, the people at this conference are
unusually passionate about their tool. I sought to understand this
blazing exuberance. I traverse several different languages and tools
pretty regularly (Java, .NET, and Ruby), and to me they are just tools
-- each has its own strengths and weaknesses. I also used Delphi
pretty much exclusively for about 4 years (and wrote one of the first
Delphi books), so I understand the tool and language. But I've never
gotten so vein-bulging-in-the-forehead excited when someone told me
they thought something else was better.

This crowd has its back against the wall: Borland's clear future
direction with Delphi is to make it Yet Another .NET Language
(YA.NL?). The last couple of versions of Delphi have supported both
Win32 and .NET capabilities (and most of the developers in Germany are
still doing Win32 applications). In my opinion, this marginalizes
Delphi to also-ran status with C# and Visual Studio. Sure, if you are
building in Delphi now and have a bunch of code, you'll stick to Delphi
(maybe). But if you are starting a new project, there is no way you
would pick Delphi over C#. The IDE isn't any better (and it is less
stable) than Visual Studio, and it will not have a version that
supports .NET 2 until mid-next year.

Tiptoeing around the fanatics, I asked a few people if the above
assessment is true. "No! The next version of Delphi will win converts in
droves!". At the end of the day, it boils down to which syntax do you
like (if the tools are at about parity and the framework is the same,
you are down to begin...end pairs vs. curly braces). I've always had an
easy time switching syntaxes, both between similar (Java and C#)
languages and very different ones (Java and Ruby). I asked some of
these folks: "Is the syntax of the language really that important to
you?" I got a resounding "Yes!" from several people. They are willing
to use a third-world development tool just so they get to type Pascal
all day instead of C#. Just like all marginalized peoples, they
overcompensate anytime someone like me desecrates the object of their
devotion.

You see some of the same fervency in the Ruby and Lisp crowds, but they
are genuinely different from their peers. The Delphi vs. C# crowd are
supporting the same platform, with different syntaxes. Would you be
willing to jeopardize your job over the syntax of a programming
language? I still do not get it.

Swiming Up the Waterfall

Sometimes, you write something that you have to keep a lid on for a little while, because you don't want to offend someone who might be reading. This is one of those cases.

A fellow co-worker and I found ourselves in a client site who was a big believer in my most favorite of dysfunctional of methodologies, Waterfall. We were hired to help them design an advanced new system (that, of course, interacted with their still very active Mainframe development) with innovative technology. My coworker and I showed up with great enthusiasm (because we didn't know what was going on yet).

Here is what we were tasked to create: First, we need a Functional Design document (a technical-ish set of requirements) to pass off to the business unit to get approval for the project (which was already approved -- that's why we were there). It took man-weeks of effort to produce this utterly useless document, which was created by emailing Word documents around, because they don't put design documents in version control (What? Did I hear that right? Why not? "We just don't" “No, why?” “If it’s in version control, others can see it”). OK.

Next comes the Technical Design Document, another multi-man-week project, where we take the Functional Design and produce a Technical Design, meaning that we finally get to reveal all the technical decisions we made while writing the Functional Design but couldn't put in that document. And we can't produce "prototypes", because that's a bad word -- business people want to see prototypes run. "Can we call them spikes? Sure, no one knows that that means". A few times, I thought my coworker's head was actually going to explode. We set up our own secret version control system and starting writing our design documents (oh, sorry, Design Documents) using XML so that we could diff them, and converted them to Word documents when the big flurry of Consolidating the Documents happened.

Then we made a decision. Given the amount of time that we had to create the Technical Design Document, we could just write the code, using XP techniques (test-first coding, iterative design, etc.) and produce the design document based on the working, tested code. And that's what we did with part of the system. We kept this under wraps (after all, we're supposed to be designing, not coding) and made good progress. To show the quality of the code, I implemented code coverage using Cobertura so that we could demonstrate that the unit tests were actually exercising the code. With just a couple of days left in the Technical Design phase, we were asked to provide estimtes as to how long it would take to implement our design. That's when we let the cat out of the bag: "Do you want us to tell you how long it would take, or how long we have left? We can give you really good estimates because it's already done". We showed them the implementation and the unit tests, along with code coverage (96% code coverage, 100% branch coverage) . The Technical Design document that was already based on working code.

They weren't upset, but weren't particularly happy either -- just kind of stunned. This way of writing software is so foreign that they have no perspective on it. They've never seen code with unit tests, or code coverage, nor any code that was produced in an iterative way. You are supposed to spend months on design documents, then write the code, right? How is it that you can not do all that? Instead of the elation that we expected, we just got a weak "Good job, guys", and they took their working code and incorporated it where it was supposed to go. We were finished with our tasks, so we left.

But not without planting some seeds. You see, we involved some of their other programmers in what we were doing. We didn't code with them, but explained how we were going about it. And we showed them unit tests (which they had heard of) and code coverage (which was new). The other developers clearly saw the benefit of what we had done. Sometimes, you can't dig a deep hole all at once because you have to move too much dirt. But a river can dig a deep hole a little at a time, eroding away grime and stone bit by bit. Even if we didn't dig a deep hole, maybe we created a rivulet.

Technology Snake Oil, Part 5: The Integration Myth

Integration is a tricky thing. When it works flawlessly, it is a huge productivity boon. But when you trust it and it lets you down, it is a huge time sink. Some examples: I used to work with someone who had a genuine fetish for tool integration. He wasted more time trying to get tools to work together than he did performing useful work. At the time, we were using JBuilder and Visual Source Safe (for my opinions on this piece of technology, check out VSS: Unsafe at Any Speed). The integration between these two tools was spotty at best. I never even tried – it was easy enough to keep the VSS explorer open alongside JBuilder and just bounce between them. But not Mr. Integration. He tried a variety of supposed integration plug-ins, each with serious shortcomings. Finally, exasperated, I told him that I had the perfect integration strategy. “I’ve fixed your JBuilder/VSS integration. First, open both of them. Second, I’ve installed a special hot-key in your copy of JBuilder, Alt-Tab. When you hit it, the VSS explorer pops up, and it works just like the explorer that VSS itself uses – it’s indistinguishable!”

Recently, another example popped up from an unexpected place. It turns out that there is a bug in my beloved IntelliJ and WebLogic, but only when you are doing distributed transactions and messaging. My colleague spent the better part of a day trying to resolve that little nasty bug.

The snake oil hiding in the shadows here is the promise of integration sold by tool vendors. IDE’s try to encompass more and more. Visual Studio has always been successful with this (especially if you use all Microsoft technologies) without achieving a truly great code experience. Visual Studio.NET 2003 is a third world country compared the scarily intuitive IntelliJ, which is the Rolls Royce of IDEs. VS.NET 2005 is better, but still not up to IntelliJ’s standard. Borland tried to take this to the extreme conclusion with its Software Delivery Optimization suite, which tried to bind together requirements gathering, version control, coding, deployment, and monitoring into a single environment. This vision yields an awesome productivity gain as long as the integration is flawless. However, integration at that level is never flawless, meaning that you spend as much time (and considerably more frustration) trying to figure out why something that should be working isn’t, only to find out that it actually is working but the integration is obscuring the results.

Some integration is good – that’s why we have integrated development environments. However, there is a fine line where vendors try to go too far and end up lessening productivity rather than enhancing it. The problem is that tool vendors are trying to create monolithic environments. I suspect that Visual Studio in all its incarnations may be the culprit here – everyone is trying to replicate that environment. Finding the fine line between integration vs. stand-alone tools is tough and going to get tougher, as vendors produce more and more immersive environments to get you to buy into their integration strategy.

Someone has done this exactly right. In the next Technology Snake Oil (Drowning in Tools), I’ll talk about that.

Technology Snake Oil, Part 4b: Prescriptive Approaches in the Large

I wrote recently about Prescriptive Approaches in the Small. More pervasive and dangerous, though, are Prescriptive Approaches in the Large. Everyone wants a repeatable pattern, a guaranteed way of doing things. Recently, at No Fluff, Just Stuff Columbus, OH, one of the questions for the expert panel was: “Our company is looking for a road map, a sure-fire prescription of what technologies, methodologies, and approaches we should take – can you provide this?” Uhhhh, no. Most of the panelists nearly crawled out of their skin to get in line to answer this question (I thought Prag Dave was going to have a heart attack – if you know him, you know this is anathema to him!). There is no prescription for software development done right in your company – every place is different. You cannot come out and say that this approach (whatever it is) is right in every circumstance.

Following this line of reasoning, I think that the PetStore was one of the worst evils inflicted on the young, innocent, fawnlike Java Enterprise Edition. It was supposed to be a catalog – “Look, here are all the things this shiny new technology can do” – and people took it as a prescription. Rather than sit back and determine for what EJB was suitable, developers dove right into using them in their projects because the prescription said so. EJB was (and is) suitable for only very specialized types of applications. If you were writing a real pet store application (even back when PetStore came out), you would be crazy to use EJB!

The pattern repeats over and over, with technology (“Everyone is using Struts, so we should be too”) to methodologies to products. You can bet that the SOA vendors are salivating over the prospect of creating the prescription that says “Everything must be decoupled, document centric messages – here, we have an expensive product that just happens to do this!” As much as it hurts, you have to make determinations for yourself on which technology (methodology, framework, tools, etc.) are best for the situation you are in right now. There is no prescription, no matter what ersatz technology doctors tell you.

Joel is Plain Wrong about XP

Joel Spolsky writes in a recent blog entry:

As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.

Joel has an interesting perspective on this subject and has written quite eloquently on this and other topics (I highly recommend his books and blog). However, I think he’s just wrong about this. He has a skewed view on software development, having worked at product companies his whole career. Building products is a lot different from building business applications (which is where my experience lies). First, for products, the requirements and design are pretty much made up of a few people’s vision on what the product needs to do. The market place determines if they were right or not. Second, you generally have to do this in secret, especially if you have competitors who will cherry pick your design. Third, you are pretty much required to do a “big bang” deployment, when you ship to customers.

Most business applications aren’t like this. The requirements are very fluid (quite often, the business stakeholders don’t know what they want even well into the process). When done correctly, the process is collaborative across business units and developers, making for a stronger product. Last, you can roll out iterations (even if just to QA and/or acceptance testing) without the big bang.

Joel is using the straw man arguments against XP. Many misinformed naysayers against XP assume that we never think about what we’re doing up front. Of course we do. This same group assumes that there is no coherent architecture for complex XP projects. Just because we’re doing agile development doesn’t mean that we just sit down and hack out code with no planning or forethought. Believe me – I’ve had lots of experience building business software, and Big Design Up Front just plain doesn’t’ work, even when it is done well (I’m fighting it yet again even as we speak). XP delivers better quality software, in shorter times, closer to the ultimate target, which has a fighting chance of actually usefulness.

Taking this topic to the logical conclusion, I wonder what would happen if a product company did a full-on agile approach? Building the product based on custom feedback from the early iterations. You would need a patient customer base, willing to comment on the work in progress. I can’t help but believe that, just as in the business software world, you would end up with a better product. How many features could you eliminate in something like Word if it had been developed incrementally? So much useless cruft could be removed from commercial software if product teams listened to their customers while developing the software rather than the complaints after it is done.

Some companies are tiptoeing in this direction. Check out JetBrains Early Access Program for innovative tools like Fabrique and MPS (The Meta Programming System). I think these products will be extraordinary if they can get their target audience to give them feedback. Agile product development – what a concept!

My Blog, in Korean

To satisfy overwhelming demand (OK, there is no such demand), Trustin Lee is translating some of my blog entries into Korean and posting them here. To quote:

I'm an Apache Committer who is still on the way of studying English. I'm trying to level-up my English skill translating great blog entries from great authors.

I think that's more than a bit generous, but I'm gladly supporting this effort because, hey, it isn't costing me anything and it spreads my meaningless opinions all over the world. What an unbeatable combination. Seriously, I appreciate the hard work Trusten is doing for this, and I hope that my dribbly writing is worth translating.

Now, I’m really interested to see if he translates this blog entry, creating a kind of recursive blog referencing stack overflow.

Technology Snake Oil

Technology Snake Oil, Part 4a: Prescriptive Approaches in the Small

The world is a much simpler place if you can just coast through it, without having to expend precious mental energy. In fact, it seems widely encouraged in many organizations: if we can prevent our employees from thinking too much, they will stay out of trouble. Unfortunately, to build insanely great software requires thought on many different levels, which doesn’t go well with prescriptive approaches.

You see all sorts of prescriptive approaches in software development, both large and small (this entry covers small, the next Snake Oil piece covers large). Small prescriptive manna floats down in many different guises, mostly in a good context like design patterns and best practices. Many developers take these nuggets out of context and start believing that this Prescription for building all types of things represents the One True Way (without bothering to apply additional thought). Don’t think that I’m denigrating design patterns – they are clearly a good thing, as a way to catalog common patterns. The problem comes in when they are used without thinking.

Here is a classic example that appears all over the Java code I see every day. Java doesn’t really have a struct-type thing, which is just a holder for data. In Java, everything is a class, which is OK. Nevertheless, I see developers who just need to pass composite data around creating a Java class with accessors and mutators that won’t every be used for encapsulation. It has become a common prescriptive practice in Java to create the class, create private member variables, and generate getters and setters for them without remembering why you create accessors and mutators. If this class is never going to have any behavior attached to it, if it is a simple container for information, you don’t need the accessor/mutator pair or the private scoping – make them public. If you really need to add behavior later and/or encapsulation, you can refactor the class into a real class, not just a composite data type.

The real sermon here is to think about why you create things, don’t just blindly create artifacts. Yes, encapsulation is generally a good thing, but isn’t required in every single thing that looks like a class – sometimes it’s really just a struct. You must always be diligent about why you are creating what you create.

Fighting for Your Life

Fighting for Your Life

I was almost voted off the island recently.

Because of some scheduling issues involving me rolling off a project, another one starting, and the slated person still a week away of rolling of his project, I was in the unfortunate position of going to a client's site for just 1 week, at the start of a new project. The first day, I arrived late because of travel details, and we spent the day going over the technical details of what it was we were going to be doing. All fine and good. In fact, one of the overviewers was kind enough to identify something he thought I could do in just a week, something orthogonal to the rest of the work.

The next day I get to work and the client supervisor asked me into his office. "Neal, we just don't think the one week thing is going to do us any good, we like you and all, but you should just go ahead and leave." He was trying to kick me off the island! The last thing he said was "Unless you can think of a good reason we should keep you..." That was my chance. I said "Well, of course, it is your decision, but I have found something I can get done in a week", and went on to tell him about the one-off sub-project we had identified the day before in technical detail. He listened to my case, then called the technical lead into his office and had me repeat it. The tech lead said "Well, we do need that piece, and I think he can get it done in a week". The supervisor turned to me and said "Alright, get back in your office and get to work!". Saved!

And it turns out that I was able to get the work done in a week, and the client requested that I stay on instead of the guy originally slated for the gig. How is that for defending your life?

An Actual, Real, Everyday Use for XSLT

I have played with XSL and XSLT for a while, and even toyed with the idea of basing my whole website on an XML+stylesheet vision. Because XSLT can get complicated, that idea died before its time. However, I recently found a really good use of XSL on a development project on which I was working. This project included the ubiquitous Log4J library, including a largish logging.xml document. My job was to make sure this document is still relevant. The problem with trying to analyze such a document lies in the way that items reference each other. Instead of pulling my hair out bouncing around in the XML file, I created an XSLT stylesheet to format the whole thing into HTML, with links from loggers to appenders and appenders to loggers. The end result looks like this (broken into 2 pieces for space savings):

The stylesheet that generates this info from the XML document is not long or complex:

<?xml version="1.0"?>
<!--  XSL Stylesheet to make it easier to determine the relationshps between -->
<!-- the loggers and appenders used in the application.                      -->
<!-- This stylesheet is automatically linked into the logger.xml document.   -->
<!-- If you are using any reasonable browser, this stylesheet should be      -->
<!-- automatically applied to this file.                                     -->


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns:log4j='http://jakarta.apache.org/log4j/'>

   <xsl:template match="/">
         <html>
           <head>
             <title>
                 Loggers
             </title>
           </head>
           <body>

             <xsl:apply-templates select="log4j:configuration" />
           </body>
         </html>
   </xsl:template>

   <xsl:template match="log4j:configuration">
       <h1>Project Loggers</h1>
       <h2>Loggers</h2>
       <table border="1">
           <tr>
               <th>Logger</th>
               <th>Priority</th>
               <th>Appender(s)</th>
           </tr>

           <xsl:for-each select="category">
               <xsl:sort select="@name" />
               <tr>
                   <td><xsl:value-of select="@name" /></td>
                   <td><xsl:for-each select="priority" >
                       <xsl:value-of select="@value" />
                   </xsl:for-each></td>

                   <xsl:for-each select="appender-ref">
                       <td><xsl:value-of select="@ref" /></td>

                   </xsl:for-each>
               </tr>
           </xsl:for-each>
       </table>
       <h2>Appender to Logger Relationship</h2>
           <ul>
           <xsl:for-each select="appender">
               <xsl:sort select="@name" />
               <tr>
                   <li><xsl:value-of select="@name" /></li>
                   <xsl:for-each select="param">
                       <xsl:if test="@name = 'File'">
                           [ <xsl:value-of select="substring-after(@value, '${logging.home}/')" /> ]
                       </xsl:if>

                   </xsl:for-each>

                   <ul>
                   <xsl:call-template name="show-categories">
                       <xsl:with-param name="appenderName"><xsl:value-of select="@name" /></xsl:with-param>
                   </xsl:call-template>
                   </ul>
               </tr>
           </xsl:for-each>
           </ul>
   </xsl:template>

   <xsl:template name="show-categories">
       <xsl:param name="appenderName" />
       <xsl:for-each select="//category">
           <xsl:for-each select="appender-ref">
               <xsl:if test="@ref=$appenderName">
                   <li>
                   <xsl:value-of select="../@name" />
                   </li>
               </xsl:if>
           </xsl:for-each>
       </xsl:for-each>

   </xsl:template>

</xsl:stylesheet>

I also added a reference to this stylesheet in the logger.xml document itself:

<?xml-stylesheet href="ShowLoggerRelationships.xsl" type="text/xsl" ?>

The beauty of this is that any reasonable modern browser will automagically apply this stylesheet anytime you double-click on the XML file. This is the ultimate form of documentation -- generated directly from the source in real time. Any changes to the relationships in the logger.xml document are instantly shown when you look at the file. If you still want to see the raw XML, you right-click and "Open With..." instead. This makes the browser view of the XML document useful without hiding or obscuring the functional elements. And is a good example of the DRY principle (Don't Repeat Yourself) from the Pragmatic Programming applied to documentation.

Technology Snake Oil, Part 3: MDA

Model Driven Architecture (or "Cartoons to Code") is the ultimate culmination of the vision of UML. Let's draw the software with diagrams, including decorations to represent logic, then click a button to generate the code. A laudable goal, but far short of reality.

The only real success stories with MDA are for very limited problem domains, like embedded software. Here's why: consider the cash register at McDonalds. The number of items is very limited, and the number of things you can do with them are very limited. This is well suited to a pictorial (in fact, an ideogrammatic) representation. That's because the concepts on display are retricted to morphemes, which in linguistic terms represents the smallest language unit that carries a semantic interpretation. Thus, it's easy to create a McDonalds cash register using just pictures and make it a quite effective solution to the food ordering problem.

For complex problems, you can't break down the problem to simple morphemes -- imagine the semantic complexities of a concept like "loan" or "payment". For a problem domain this rich, you need the richer representation of a full-blown language (which the Egyptians also discovered -- they were the last MDA success story, and they eventually abandoned it!). Trying to cram rich semantics into a pictorial representation so that you can create software that abstracts those semantics is absurd.

In fact, trying to cram the entire world into a strict tree-shaped hierarchy isn't much better (see Programming, Object-oriented). At least OOP has more flexible semantics, and we keep forcing solutions to this hierarchy problem with inventions like aspects, which cut across the tree-shaped world we've created (because stuff in the real world cuts across trees). So, where do we go from here?

Let's solve it the same way mankind (including the Egyptians) did -- create language! Language is ultimately the only way to handle the rich semantics of the world around us because that's what the people stating the problem domain use to state the problem. Which is why I'm so geeked about Language Oriented Programming -- building domain specific languages that are as close as possible to the problem we're trying to solve. LOP done right encapsulates the low-level details of a language like Java, allowing developers and others to work at a higher level of abstraction. We've been mired in curly-brace languages too long -- we need to upgrade our abstraction.

MDA is the wrong direction for abstraction upgrade. It tries to further restrict our expressiveness, believing that the entire world can be graphed and you can create real software this way. Imagine for a moment the MDA diagrams (including Object Constraint Logic) for your average J2EE enterprise application. You can build it in code, with the crude semantics of curly-brace Java in 1/3 the time you could model it to the point where you can click the "And Then a Miracle Occurs" button to generate the application. MDA might work for simple, semantically unique domains, but no where near the real world.

Happpy with What You Have to be Happy With

Recently, I did a 3-hour tutorial workshop at the SOA conference in Singapore entitled "Agile Development and SOA", where I talked about aspects of Agile development as it applies to SOA type projects. Mostly, it was an excuse to talk about Agility in a foreign land.

I asked the attendees what type of methodology they were currently using. The three replies I got were 1. None (what's a methodology?), 2. Waterfall (although she didn't know that name for it), and 3. SDLC (the Software Development Lifecycle (another variant of Waterfall, check out this interesting Wikipedia image of SDLC )). So, basically, everyone is using some form of Waterfall. What's interesting is that I asked to most vocal of the crowd (meaning that she would actually answer without me jumping up and down on the table in front of her -- she was the SDLC victim) if her company was happy with that methodology. She quickly replied "Oh, yes, it works very well for us". Needless to say, I was surprised. So I asked her a few follow-up questions:

• Do you ever miss deadlines? Oh, yes


• Are your user's happy with what you produce? Well, no


• Are your developers frustrated by vague requirements, which leads to user dissatisfaction? Yes


• Do you ever accidentally break code in your "big bang" deployments, which takes a long time to fix? Yes

I asked a few more, but you get the gist. She thought they were very happy with SDLC because they didn't know that something better existed. Perfect crowd for an agility talk, right? It was an uphill battle. No one could believe that this crazy idea could ever work -- waste all that time writing tests? Include the users as part of the development team? Pair Program?!? That cuts your productivity in half! Sigh. I waged a good battle, but don't know how well the war is going. At the end of the talk, I had either convinced them to tip-toe towards Agility (because these were developers -- can you imagine what their boss will say?) or they were just tired of me talking about it and said anything to get me to shut up.

I've blogged about this phenomenon before -- why is it that developers and managers believe that all forward progress in methodology stopped in the mid-70's and all language development froze about the time Objects appeared? Is it just a non-technical person's fatigue at trying to keep up, so an arbitrary milestone was created beyond which "I won't think about it anymore?" Are developers so overwhelmed that they just shut down too, and keep working on what's in front of them even though better things abound?

Technology Snake Oil, Part 2: RAD

Back in the mid-nineties, Rapid Application Development was the answer to all developer woes. RAD tools came out in droves and everyone touted the huge productivity gains made available by drag and drop user interface design and component based development. RAD environments made for great demo-ware -- you could stand in front of a group of Pointy Haired Boss types and build a working application right before their eyes while you were talking about it (I know because I did some of this -- and I still have trouble sleeping sometimes). Of course, the message was clear: buy This Tool, and you too can have developers that can point and click their way to huge productivity gains. And bought it they did.

Then a funny thing happened to the developers on the way to this astounding productivity. They learned the tools and dutifully dragged and dropped their way to building applications...and it was good. Until, that is, they figured out that building the application is the short, easy part -- now they have to maintain the monstrosity they've created. RAD development doesn't scale well, and when you build large and very large applications with it, maintaining those applications is a nightmare of searching for the scattered crumbs of code scattered hither and yon. Working for a while in this environment is what made the Design Patterns book really hit home -- the kind of code we were creating was entirely anti-pattern, and more about "how fast can it be created"? The maintenance nightmares led me, as CTO of a consulting and development company, to figure out new ways to use the RAD tools we had to use (because of our clients) that did follow good design principles. What we found is that the tools fight you when you try to do the right thing. RAD Development tools have a path of least resistance, which makes things very easy while you stay on the path (and use their wizards and other support structures). Stray from the path, and you find obstacles at every turn. But, it's worth fighting through them to get to a place where you can create maintainable code -- and you find that you are no longer doing Rapid Application Development, just Application Development.

RAD is now rightfully deprecated in most serious software development efforts. Even serious developers using RADish tools like Visual Studio are avoiding the RAD pitfalls. Some developers still fight with RAD tools, and think that maintenance is just always extremely difficult in big projects. I'm still shocked by the developers who have still never heard of Design Patterns and who still work on Sisyphean development chores.

Which is why I think the RAD aspect of Ruby on Rails misses the point of what makes Rails interesting. RAD doesn't work for large, complex projects, no matter what technology. The interesting part of Ruby on Rails is the effective use of Ruby to build a domain specific language on top of the underlying Ruby language that makes it easier to do web applications with persistence. It is more advanced than the RAD tools of old because you can drop to the underlying Ruby language and get underneath the framework when you must -- and that's a powerful idea. But, building complex applications in it still requires real thought. Maybe the breathless amazement of the Rails community reflects the absence of effective RAD tools in this space before. Don't get me wrong -- I think that Rails is cool, just not for the reasons touted by so many Rails-flavored Kool-aid carriers.

Technology Snake Oil, Part 1: UML

I was told by someone recently at ThoughtWorks that I was so old that I "added to the company's diversity". Well, I've decided to take this sage old-timers wisdom and put it to some good use. In the development world, we keep getting sold Snake Oil in one guise or another, and I'm going to start pointing out some snake oil. Starting with the most venerated of crappy technology: UML.

Some of us craggy old-timers remember the time before UML, when we had Booch, Rumbaugh, and several other competing diagramming notations. The Holy Grail was going to be the Unified Modeling Language, which would solve all our problems and finally give us software developers a universal language, for everything from use cases through structure to deployment. And that's what we got. A classic example of "be careful what you ask for". UML feels like a compromise between a group of people, and it's so general that it's almost useless. The standards bodies keep bolting on new stuff to try to get it to the point of basic usefulness, but it just makes it worse. Does anyone really use Object Constraint Language to decorate their diagrams so that they can generate code that Just Works? I have never seen a case where you couldn't get it done faster by writing the code, then reverse engineering it into one of the expensive tools. Of course, it's good to design things before you code them, but a white board is much better. Combine the nature of UML with the fact that you can't ever show its diagrams to business analysts or end users because it is too obtuse, and I end up doing most of my architecture and design work in Visio (and I'm no fan of it either). It creates diagrams you can show everyone that capture the essence of what you are doing just before you implement it.

I'm not just a tourist in the UML and RUP world -- the company I worked for in the dim and distant past used RUP, and we foisted Heavy Duty Object-oriented Analysis and Design on clients, and used it ourselves. Why do you think I'm so militantly agile now? It just flat doesn't work for 90% of the types of projects that real developers write. And it's Bastard Child Model Driven Architecture is featured in an upcoming Snake Oil entry...

SOA (Service Oriented Aberration)

While talking to some of the other speakers at the SOA conference in Singapore, it occurred to me that SOA has an interesting side effect that has nothing to do with technology. To make SOA really work, a business has to strictly define what it is they do, to the point that a developer can create services to represent it. That's the rub -- most businesses don't understand their own business to that level of detail. Time and time again, I've noticed that the analysts and developers on a project actually define a client's business processes to a much finer level of detail than the business ever has. To write code for something, you have to really understand it. Some of the clients for which I've worked even commented on the fact that, because of the development process, they understand their business better.

Of course, the opposite is also true (and, alas, more likely) -- companies with poorly defined business processes will try to adapt SOA and fail miserably, creating a case study of SOA failure, when the technology had nothing to do with it. Worse yet, tool vendors of expensive development tools like Enterprise Service Buses will sell their tools to unsuspecting clients as a way to "fix" their business process. Putting a dress on a pig doesn't make the pig any prettier, and it just annoys the pig. SOA, like so many other similar technological breakthroughs (see Programming, Object-oriented and Development, Component-based), won't solve the dysfunction of dysfunctional businesses.