Ruby on Rails Makes Me Happy

Last year I got to work on my first Enterprise Rails application and although there were some brief moments of coolness, that project was punctuated with a lot of things that just made it suck overall. In fact, I was doubting that bringing Rails to the enterprise would be a good thing. There were just to many other things wrong that had nothing to do with the technology.

But half a year later our enthusiasm for Ruby on Rails hasn't been seriously diminished despite a less than stellar project, and surprisingly our commitment is growing. From three developers doing Rails we've grown it to five and my managers have fully accepted it and are pushing it forward for most new projects.

Excitingly for me, I was recently assigned a small but very high profile project. And this time I think I've been able to do things the best way I know how in a very short period of time. The controllers are RESTful, my routes are appropriately nested, the layouts are clean table-free HTML with CSS and the Javascript is unobtrusive. I really dig Prototype and the app is sprinkled with just the right amount of AJAX and the Scriptaculous effects are not gratuitous.

Quite honestly I'm pretty thrilled with this app. It's only been a week or two worth of effort but it's been thoughtful and extremely efficient. So efficient that I think the app will be fully functional before the TQA and Production Tomcat servers I requested will be provisioned by the server team (remember I'm in a big enterprise). And yes, you read that right I'm deploying to a JEE web container. I'm past any trepidation I may have once harboured about JRuby vs MRI Ruby. To me it's a proven part of my deployment strategy that I can depend on.

Anyway I'm a happy developer again. I'm getting apps written and deployed for my users and I love the look of my code. The cool thing is that Rails keeps getting better. Rails 2.3 is just around the corner. I like the application templates and the integration of Rack. I still have to bring up my testing game but give me another week and I think my tools of choice (RSpec, Remarkable, and FactoryGirl) will have me cranking out better test coverage than I've ever had before.

Anyway let me wrap this up with some of the things I think are wicked about Ruby and Rails and the various gems:

• pluralize
• belongs_to, has_many :through (declarative ORM)
• Model.all
• Model.paginate (will_paginate gem is awesome)
• link_to_if
• select, collect, each (collection methods are cool)
• statement if expression (statment modifiers rock)
• distance_of_time_in_words_to_now
• model_url
• before_update, before_delete
• validates_presence_of, validates_length_of (declarative validation is sweet)
• Ruby, a REAL language, in my view templates!
• jruby script/console oracle (interacting with Oracle through my models via JDBC)
• rake war:clean war (Thank you warbler)
• script/autospec (even better on my Mac when integrated with Growl)
• ActionMailer with layouts (my HTML emails never looked so good)
• Ajax.Request, Ajax.Updater (Yay Prototype)
• case (yeah just a nice simple case statement)
• auto_discovery_link_tag and builder (yeah I added an RSS feed for good measure!)
• Railscasts (an exemplary example of a great community, Ryan Bates you rock!)

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...

Embracing Change

When I consider the "agile software development methodology", a key principle that comes to mind is "embrace change". The theory is that users don't really know what they want. They'll only be able to steer you to the goal once they see something working. So get ready for change. They'll change their minds a bunch of times as the software evolves. In the end they'll appreciate your flexibility to adapt the software to their changing vision and you'll be a happy developer because you've created something that will actually be used and appreciated by the end users.

But what happens when it's your team leader who keeps changing the technologies under your feet? Is it just another kind of change to be embraced? Let's see...

The elaboration phase of the unified process can be defined as: "This phase attempts to create an executable architecture that realizes architecturally significant use cases." In other words, we should select the appropriate technologies that will be needed to create a solution for the most difficult known use-cases and then actually prove that our chosen technologies will do the job by creating executable software. Then during the construction phase, we should be ready to tackle the problems (known and yet to be discovered) with the technologies in hand.

A second core principle of the "agile software development methodology" is "You aren't going to need it", which means you shouldn't overengineer something because you think you might need it in the future. Keep it simple. The idea is that you save time by not doing it now and you make your code better and more maintainable because it's simpler. If someone ever says to you "if we build it in now, it'll save us time later" and you already have too much other work to do right now, then tell them to forget it.

I'm currently in an environment where every "senior" resource is on a mission to turn the management spotlight on themselves and the way they try to achieve that goal is to way overengineer the solution with as many Java frameworks as possible. By doing so they can prove their technical merit with a complex solution. To give you an idea of what I mean consider this:

We have a framework for dependency injection, we have one for database persistence, we have one for role based security, and one for binding XML, we have one, no wait two (or maybe three) for doing UI. We're in the process of adding yet another Java web container (without retiring the previous two) and have added every conceivable open source code measurement and style checking software. We have two continuous integration servers and in addition to the JUnit testing framework, we're adding Ruby/Watir testing too...

Individually and maybe with some intelligent selection I don't have anything against most of these frameworks (except for Spring) but after six weeks of development with 9 programmers with only a login screen to show for it, I say enough is enough. Java web development may not be as productive as it is with Ruby on Rails, but it's not this tough!! Come on! Look at the requirements and choose proven frameworks that address problems you've identified and don't cost more to implement, learn and maintain than it would cost to create a custom solution. For example, if you have to spend more than a couple weeks implementing a role based security framework when nobody has actually said you need to worry about different roles, then you're probably doing something very wrong. Keep it elegant, efficient and simple.

DHH Interview

I just found a SYS-CON.TV interview with David Heinemeier Hansson that had some real quotable moments:

In his description of Ruby On Rails:

...we like to consider ourselves the Apple of open source web application development...

...it's extremely conventional. Most of the ideas in Ruby on Rails are the same ideas people have been building web applications on for the last ten years. They just hurt a lot less...

On Convention over configuration:

...In Java we call it XML sittups. You can produce just as much XML configuration as application code and that's just insane in our mind...

Does it scale?

...unquestionably yes. simply because Ruby doesn't invent a new architecture. We use exactly the same architecture as people who have been building the biggest sites on the internet.... shared nothing...

On the value of Rails.

[People think] it's so valuable to have extreme performance when there are tones of other attributes that are more valuable: programmer productivity, how maintainable your application is over time, ...

Agile or Traditional?

I was recently speaking with a friend I haven't seen in months and she mentioned that she was reading a book I had lent to her. The book is called "Balancing Agility and Discipline" by B. Boehm and R. Turner. The book's main theme is the attempt to balance agile software development methods with traditional methods. The idea is to try and assess your project by looking at several different characteristics and then choose the processes from each method that will allow you to best manage it.

So that idea got me thinking about my most recent project, a Java rewrite of an existing application, and how desperately we were trying to use a pure agile methodology when it didn't really fit.

Here's a quote from a presentation available on the "American Institute of Aeronautics and Astronautics" website:

Problems characterized by change, speed, and turbulence are best solved by agility.

• Accelerated time schedule combined with significant risk and uncertainty that generate constant change during the project.

Is your project more like drilling for oil or like managing a production line?

• Oil exploration projects need Agile processes.
• Production-line projects are often well-served by rigorous methodologies.

Our project was undoubtedly a production-line application with very low risk:

• Although I didn't really like the technology we used on this project, it was being used to some degree of success on two other projects. So while it was undoubtedly not very productive, it was usable.
• The database design and user interface design were to be lifted untouched from the existing application.
• We were mandated with reproducing an existing production application so the requirements were well known if not well documented.
• Business users were not co-located and not easily reached for consultation (during the entire project I never spoke to a single person who would actually use it).

So what drove us to try and use an agile methodology? Well.... it's trendy. Agile is "in" and waterfall is "out". IT people would like to live in a world of absolutes, where we can say with certainty that A is better than B. But the reality is that we live in a world of spectrums where things are classified in terms of a position on a scale between two extreme or opposite points. Just like we shouldn't try to develop a simple project using every conceivable J2EE technology and framework available, maybe we shouldn't try to apply every agile process available where it just doesn't fit. Sometimes it's okay to create a plan and to write down requirements. Sometimes it's the best thing to do.

Suffering

One of the Pragmatic Programmer tips is:

"select" Isn't Broken.

Which means that's it is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application, i.e., my code.

The problem with the project that I'm working on is that there is so many layers of code and abstraction that I don't even work with the framework anymore but some class ten times removed.

For example I have a JSP calling a JSF configured backing bean, calling a Spring configured service, calling another Spring configured EJB in a different process, calling another Spring configured service calling another Spring configured DAO which is (eventually) a subclass of Spring's HibernateDaoSupport class which attempts to hide Hibernate's API altogether.

So while I try to take the tip seriously and not blame the framework, there is so much stuff happening before it even gets to Hibernate (and let's not forget all that XML goo that glues everything together) that I can't help but lay some blame at the feet of these frameworks that encourage so much obfuscation.

To get real geeky I'll quote C3PO from the original Star Wars movie:

We seem to be made to suffer. It's our lot in life.

Manifesto

Everyone has a manifesto nowadays. I just read an interesting entry at the "Creating Passionate Users" blog that pointed to the the 37signals manifesto. Both recommended reading.

Testing

I came in to work this morning only to listen to a QA lead and a senior developer discuss the almighty importance of tests (specifically unit tests). "They are the specifications, blah, blah, blah". But you know what I didn't hear, the importance of the actual software itself! Agile-development, test-first, test-driven, whatever-process-comes-next are all well and good but don't get so damn attached to it that you don't focus on what's really important, the software. Don't get me wrong, tests are important but they come a distant second to the system under development.

Work's a drag

A few Pragmatic Programmer tips are:

1. Provide Options, Don't Make Lame Excuses
   Instead of excuses, provide options. Don't say it can't be done; explain what can be done.
2. Don't Live with Broken Windows
   Fix bad designs, wrong decisions, and poor code when you see them.
3. Be a Catalyst for Change
   You can't force change on people. Instead, show them how the future might be and help them participate in creating it.
4. Remember the Big Picture
   Don't get so engrossed in the details that you forget to check what's happening around you.

And I try to live by that... But with so many developers heading in different directions trying to prove how smart they are, I feel like I'm riding in an out-of-control freight car. The momentum is too huge to overcome by myself.

During some informal polling among other developers I get a pretty divere set of opinions. Some agree with me (but not on the same remedies), others are apathetic, and others feel that everything is just fine. So naturally I don't feel that comfortable pulling the handbrake. I just hope there isn't a sudden stop and a loud bang associated with this ride.

I guess there's a reason they call it "work".

Remarkable developers use remarkable technologies to do remarkable things.
[...]
If you don't have passion for software development you will not become a remarkable software developer, period.

- Chad Fowler

Chasing simplicity in programming

A new article on c|net discusses the new phenom "Ruby on Rails". Quotes from the article:

Like Java did a decade ago, Ruby on Rails is getting developers excited by making them more productive

The vision of Ruby on Rails, or RoR, is to combine the speed and ease-of-use of scripting language PHP with the "clean," structured approach of Java

Java Enterprise Edition software is a "complex monstrosity" that's hard to learn

Research company Burton Group recommends that corporate customers consider Ruby on Rails for new Web development projects

We took a pretty radical stand: Stored procedures and all things that make your database clever are evil

Dave Thomas on TSS

Dave Thomas is one of the two pragmatic programmers. The Server Side posted a transcripted video interview with him. Lots of great stuff discussing the differences between:

• Test Driven Development and Test First Development
• Agile and Extreme Programming
• Strong Typing and Dynamic Typing
  

It's hard to argue with what he has to say. Definitely worth a listen/read.

LuntBuild

Having experienced (over a year ago now) the setup of Cruise Control (to do continuous integration of Java projects) and being thoroughly underwhelmed by the quality of that software I was quite happy to discover LuntBuild today. Bonnie, another developer at our site, set it up on one of our servers so that probably contributes to my positive experience, but setting up a scheduled build complete with the CVS extract, the call to my existing Ant script, an automatic labelling of successful builds and an e-mail to notify me of build success was a point and click affair and was done in about 20 minutes. Nice!