Mono (C#)... 4 years later

It's been 4 years since I first started looking at C# and in particular Mono. Since January 2005, I took a course on C#.NET and even worked on a project or two, but I can't seriously claim that I'm a big .NET guy (yet). I continued to work in Java and a whole lot more with Ruby and Rails (thanks to JRuby). But just like I said 4 years ago, I'm a pragmatist about these things. Since Calgary seems to be moving to C#, I figured I should probably take a look at the lay of the C#.NET land again.

I'm still a Mac-toting fan boy and don't really want to pay for a Microsoft OS license or pay for their IDE so Mono is the only game for me. So I headed over to the Mono website. I was ecstatic to see that MonoDevelop finally works on a Mac. So I downloaded the latest Mono runtime and the latest beta of MonoDevelop. I installed both without a hitch and proceeded to build an ASP.NET MVC webapp in just a few minutes. No fuss, no muss, it just worked... Very cool.

I still work in Rails most days and in my spare time I continue to work through an iPhone App development course so Mono isn't going to get a lot of attention for a little while, but it's out of the fridge and on the back burner...

Quicktime X A/V Controls

I've been (very slowly) working my way through Stanford's CS193P iPhone development course available on iTunes U.

iTunes is a pretty good client for watching the lectures. It keeps track of where you were and if you're like me and your lecture viewing is frequently interrupted (i.e., kids), that can be a pretty useful feature.

But one of the things that it won't do is allow you to speed up the playback (at least I don't think it will). So when the instructors are talking about due dates, late assignments, and other housekeeping that doesn't really apply to you, it can be frustrating to watch through it in realtime. So if you can live without iTunes' ability to track progress, simply go find the movie on your hard drive (right click and select "Show in Finder") and open it up in QuickTime Player.

In Leopard open the "A/V Controls" window in QuickTime 7 and set the playback speed (up to 3x). After installing Snow Leopard I was sad to see that the A/V Controls window was missing from QuickTime X so I assumed you had to use the optional QuickTime 7 installation. But tonight I tried option clicking the fast forward button in the QuickTime X Player and discovered that instead of increasing the playback speed to 2x, 4x, or 8x when you repeatedly click the button, it incrementally increases the playback speed by 0.1x up to a maximum of 8x!

So there you go. Save some time and learn some iPhone development too.

Put Out to Pasture

I can't help but feel a bit unwanted and put out to pasture... You see my development group has just been moved out of the building where the majority of our users work. While it comes as the result of another business unit demanding our office space (they're more important than us), it feels like just another step in what has been a long progression to outsourcing.

The History

At some point Management got hold of the term "core competency" and started to go wild with it. They figured that since their "core competency" was Oil and Gas, that they should outsource all other non-core functions. Since they didn't understand IT and didn't want to seek to understand, we became the obvious target.

Management's (evolving) Plan

Step one: get rid of all the technical people. If you were technical then there was no position for you as an employee. But that didn't quite work as expected because everyone just became an independent contractor. You had the same people doing the same work in the same offices. You officially reduced head count, but you were paying more for exactly the same service.

Step two: Put 3rd party companies between you and the independent contractors. You centralize the billing and satisfy some taxation laws (the people no longer look like employees) but you're still paying more because these 3rd party companies who really don't do much still have to make a buck.

Step three: Remove their ability to talk directly to the users. Insert a new group of "Business Analysts" between the technical people and the users. Now you got a nice buffer zone. The thinking goes something like this: These business analysts will be the liaison for the users and the technical people. They'll be able to speak both business-speak and techie-talk. Since we never really understood what those technical people were saying and suspect that they were always trying to bamboozle us, we'll trust the BAs to keep the techies in line.

Step four: Round up the techies. They were distributed all over the place before and were actually sitting with the business. Can't have that. Put them all together in one team where they can "learn from one another" and make sure that they have to get all requirements filtered through our BAs. The BAs are better at determining requirements anyway and write lots of nice impressive looking documents. This is looking good.

Step five: Move the techies somewhere else. The business people can still talk to the techies. Dammit! A couple floors and an elevator ride are not enough. Move them to the basement or even better another building!

Step six: Outsource. All techies are the same. Replacing them is easy now. The BAs are now in control and all those fabulous documents they create are wonderfully accurate and complete and easily implemented by some faceless drone somewhere else. Mission accomplished!

The Reality (before step six)

The BAs (for the most part) neither understand the business nor do they understand the technology. They were either the incompetent technical people or the incompetent business people that the company didn't know what to do with. Ahh perfect, make them BAs. Somehow they'll be good at that. At least they're blissfully unaware of their role in all this.

The technical people who do the actual work are unhappy. They feel marginalized and unappreciated. They want to use agile software development techniques and improve their craft. But with BAs who don't understand Agile and who more often than not run the projects (with a surprising lack of project management skills) that gets axed. Unit testing goes out the window, independent QA is curbed, and directly speaking with the users is prohibited. The requirements documentation is understandably flawed and incomplete. Communication is strained, scope is fixed and because they know better the BAs fix the timeline. Through individual heroics software gets pushed out the door but the bug counts are way up.

The users are frustrated and stuck with an unworkable process. Projects take forever, response time for fixes is slow, and they very rarely get what they need. Results are invariably poor but regardless of feedback to IT things don't seem to improve.

Upper management is seeing their vision implemented and are happy. They are blind to the pain their decisions have caused.

The Fix

Realize that IT is a part of doing business. You can't avoid it. Yes it's a frustratingly complex problem and a sometimes difficult-to-understand creative endeavor but it's necessary. Agile software development techniques have evolved out of decades of failed projects and painful experience. It is designed to address the communication problems and deliver working software in the most expedient way possible. Sure it has its problems too but adaptation and evolution of the process is the way forward. Tying things up in ever greater amounts of bureaucracy and politics despite your best intentions is ridiculous. Understand that IT is part of doing business and embrace it instead of trying to push it further away.

So why do you do it?

That was the question a member on my team asked me when I said "even though our team has a bright Ruby and Rails future it doesn't seem like anyone else in Calgary does".

You see he's not a Java developer or a Ruby/Rails developer but rather a data warehousing/ETL expert, and after hearing us rave about all things Rails he thought it might be a good idea to pick it up too. I didn't want to discourage his exploration but I also didn't want to give him the impression that in these tough economic times that being a Rails guru was really going to turn him into a hot commodity. That's plainly not true. In Calgary, it seems like the wind is in the sails of the Microsoft .NET community.

And while I don't despise C# (or Java for that matter) I don't have the affection for those technologies that I do for Ruby and Rails so his question threw me off. And he has a point, if it's not going to improve my marketability as a developer outside of my current contract then why in the world would I choose to develop non-mainstream skills?

Well for me the answer is easy. I've worked with Java for about ten years and done the odd C# project or two so I feel pretty confident in my abilities to use either one if I have to (C# just isn't that different from Java). But that's the point. My current environment doesn't make me use those technologies so I choose not to because I know I can be more productive with Ruby and Rails. In other words I can provide more value to my client for the same amount of money they're spending to have me sit there. I can deliver software to my users faster than I can with the other mainstream choices, and I can do it with less code that is better tested and I think more maintainable. And although I know there are developers who like to squeeze every billable hour they can from their client, I prefer to deliver so that my users have a positive experience. My theory is that the positive experience will make them think of me the next time a potential project rolls around.

That's why I do it! And oh yeah, I love it too. :-)

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!)