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.