Enterprise Software? You gotta be kidding me!

If you create truly mediocre software for a vertical market in a mainstream technology like .NET, fill it with buzzwords like "web services", then the truly ignorant will shower you with bags of money. Apparently that's the recipe to becoming a success. Hard to believe isn't it? Well I wish it weren't true but it must be. Otherwise I have no explanation for the project that I'm working on.

Recommendation #1. Make it real ugly.
I commented earlier this year about the ugly UI, and since then things haven't gotten much better as I've started to dig around under the covers. The entire UI is driven via metadata. Nobody actually designs this interface to help the user solve his problem. Hell no! That's way too much work. Instead, tell it there's a new column and it just adds it the the grid. Wow. That's brilliant. Yeah it's ultimately flexible and configurable by every single client but then you end up with one ugly generic UI. Where's the dialogue between designer, developer, and user about what's critical?

Recommendation #2. Use .NET specific types in your Web Services
Because this is largely an integration project we tried to follow the vendor's recommendation to use their "platform-neutral, next-generation, SOA compliant", web services. Well that turned out to be a bust because their crappy implementation simply returns a serialized Microsoft .NET DataSet that no other toolset (including AXIS for Java) seems to be able to understand it. We ended up using a TCP/IP monitor to reverse engineer this abomination just so that we could figure out how to call it. And if you've ever looked at the XML of a serialized dataset you'd know immediately that this isn't something you should be exposing to your clients in the first place. It basically opens the kimono and says "here's my data model". So now there's zero abstraction from the database. If it changes then so does the web service. I can see that being nice and stable. Not!

Recommendation #3. Release often and change your external API.
Trying to write some code on top of something that changes all the time is like building a house on mud. Just yesterday, we discovered that their latest version of the app has a subtle change in the URLs for the web services. Suddenly none of our code worked. (BTW: I argued that we should test this thing before just dumping it on our servers but nobody listened).

Recommendation #4. Make ridiculous claims and milk your clients for consulting fees.
The vendor said it works with Oracle to make the sale but their consultant, who came onsite for a week to troubleshoot the performance problem, made the astounding pronouncement: "it works faster with SQL Server". What? What about the promises you made before and are you sure that'll fix anything? During our load testing we discovered that the CPU utilization on the database server is minimal regardless of database flavor. It's the application server that's pinned! How come they didn't mention that?

Conclusion Make crappy software for a niche market whose users are dumb enough to get dazzled by a flashy demo. Then sell a license for some exorbitant fee and just start milking them with expensive consulting served up by people who don't have a clue what they're talking about. Sure your users and their pathetic IT staff will grow to loathe you, but hey you already have their money and there's always another sucker knocking on your door just dying to buy your "enterprise software".

Or you could just Get Real...

Ruby on Rails demo

Yesterday I gave my co-workers a lunch time presentation about Ruby on Rails. Since these guys haven't even seen Ruby, never mind Rails, I kept it pretty basic and loosely based it on DHH's build-a-blog-in-15-minutes screencast at RubyOnRails.org. I coded live and in person and even the mistakes I made were good because they highlighted not only Rails' good error reporting but also the quick edit-and-refresh-the-browser style of coding. No Ant scripts, no compiling, no restarting the app server, no waiting for the VM, etc.

In the end I think I made the impact I wanted. I showed people some other ways of developing web applications that are fundamentally more productive than the endless configuration hell we Java developers tend to work in. Unfortunately, I also heard unfortunate statements like "that's cool but we're a Java shop and we'd never be able to deploy something like that". While that was disappointing, I kept my composure and plugged JRuby as a possible future solution (I can't wait to be able to a build a Rails app into a WAR and deploy it in WebLogic).

I planted the seed. Now all I have to do is continue to nurture the idea of Rails development, continue the education and hope for a brighter future.

Tim Bray: PHP, Rails, & Java

Tim Bray, of Sun Microsystems, set off a little bombshell with one slide from a presentation he gave at the International PHP Conference. The slide in question compares PHP, Rails, & Java on four separate criteria: Scaling, Dev Speed, Dev Tools, & Maintainability. Rails won on Dev Speed and Maintainability and PHP won the scaling contest!

The presentation even goes on to talk about the WS-* specs being too complex (he even borrowed DHH's WS-Deathstar slide). Who would have thought things like this would be coming out of the mouths of people at Sun? Can't say that I disagree... Fewer lines of more readable code should mean greater productivity and better maintenance. That seems like a no-brainer.

Code Generation with Ruby

I just watched some parts of a Google Tech Talk Video about code generation. It was a videotaped presentation by Jack Harrington, the author of "Code Generation in Action" to some of the developers at Google. I didn't find most of the presentation to be that interesting, but there was one snippet of Ruby code that I liked. It looked something like this:

require 'erb'

File.open('./test.txt', 'w+') do |f|
  name='Darcy'
  erb = ERB.new(File.new('template').read)
  f.write(erb.result(binding))
end

My template file was a single line that contained this: "Hello <%=name%>". I think you can probably figure out what the result would look like ;-)

The real example he used in his presentation was slightly more elaborate in that he had a source of data, an XML file, and he used REXML (a great XML library in Ruby) to read the source to generate a SQL file.

I'm not a big advocate of code generation but if you find yourself in the unenviable position of needing to do it then this is a great place to sprinkle in a little Ruby magic.

Sucking the Fun Out of Software Development

Last week I found myself being subjected to one of the worst fates known to the North American cubicle dweller... the dreaded team building meeting. Acckkkk!!!

But even worse was that the typical mind-numbing "personality profiling exercise" was replaced with the excruciating "enterprise architecture presentation".

Where do these guys come from anyway? Who uses words like "end user vision", "long range target architecture", "governance board" and garbage like that?

Quite frankly I don't have the patience for it. If you get a thrill trying to out-merriam-webster a bunch of other like minded architecture zombies then all the power to you, but don't come to my precious team-building meeting and make things worse by spouting that meaningless drivel at me.

I tried to pay attention in order to show some respect for my fellow man, but before I knew it I felt like Charlie Brown listening to his teacher, mwah-mwah-mwah...

So I first started sketching to try and relieve the tedium but soon found myself writing down a bunch of words to describe the corporate architecture team and this crap presentation. Here's what I wrote:

• bureaucratic
• roadblocks
• undemocratic (appointed)
• not a meritocracy
• unrealistic
• double talk
• expensive

Does that list remind you of anything else? Well I dunno about you but my mind goes straight to several branches of the government. Uh oh...

Anyway, my point goes back to the stuff that DHH talks about all the time:

1. Beauty leads to happiness
2. Happiness leads to productivty
3. (therefore) Beauty leads to productivity

Maybe, just maybe, if these IT departments would just stop sucking the fun out of software development, then maybe, just maybe, we could get back to actually delivering some real value to our clients. I'm not saying that we should completely ignore architecture or good design, but if you've somehow let your focus shift from delivering value to your customers to creating Powerpoint presentations full of words that nobody understands just in order to try and sound important then please find someone who cares and get out of my face so that I can get back to what really matters!