ntschutta.com

Software is full of ilities - those quality attributes that more seasoned veterans (or anyone that thinks beyond today’s quarter) care an awful lot about. Some common non-functional requirements bandied about include scalability, reusability, flexibility, testability, availability, usability, adaptability, maintainability…really we could go on and on. Individually, none of these is more or less important than any other though depending on what you’re building for whom, certain attributes are given more or less weight. If I’m working on a simple app to manage my wine collection, I probably don’t care too much about scalability. But, when designing a ratings engine to process thousands of transactions, my concerns change. To put it succinctly, it depends and its always about tradeoffs.

Lately I’ve noticed a lot of projects value dateility above all else. Now, this isn’t necessarily a bad thing. Say you’ve got an important industry conference in six weeks and you need to have a demo ready or on the close date of a merger the books have to be unified - I’ve been in situations where hitting a specific date really was critical to the success of the project.

But then there are those times where the date is arbitrary, it’s pulled out the hat by some manager or VP in an effort to please their bosses or curry favor with the person cutting the checks. I remember one project where the importance of the date was reiterated to us again and again, only to be told at the holiday party that the plan really had us finishing a couple of weeks after the all mighty date. That didn’t sit well with those of us logging all that extra time and we spent most of the next month cleaning up the code in preparation for the next march.

Of course dialing any ility to eleven means others will be turned down to compensate. When we focus on the date at all cast, we stop testing, ignore best practices, and we’re left with a ball of mud. We might have “saved” a little time, but odds are we’ve cost ourselves significantly more in the long run. When building a house or a bridge, the consequences of shortened schedules are easy to see; with software, it’s harder to diagnose but no less real. High defect rates, difficult to use systems and high estimates for new feature work are typical markers of a rushed project.

The affect on team morale is evident to anyone that cares to see it. Nearly everyone I’ve worked with genuinely wants to do good work, they want to take pride in what they’re building. When forced to do a half-assed job, they don’t take it well. The key is saying no, to build less, but finding a manager or VP willing to do that is nigh on impossible. Agile techniques help, but culture trumps all - if people are rewarded based solely on hitting a date, success will be redefined to make sure the maximum bonuses are paid out.

In my Test Infecting talk, I do my best to counter a number of myths that I (and others) have encountered when introducing testing into an organization. One of the most persistent misconception revolves around time - or rather the lack thereof. Many a developer has claimed they don’t have time to test to which I generally reply with a Pat Parelli quote from this post on Kathy Sierra’s blog:

“Take the time it takes so it takes less time.”

Kathy was talking about multitasking but my point is simple: forgo testing and you’ll pay that price plus more later when the defects start rolling in. While I *think* this is persuasive, Dean Wampler went one better by using charts which we all know makes for a better argument Dean makes some great points in Why you have time for TDD (but may not know it yet…) though the part about moving unscheduled project end time up earlier into the project really hit home.

Ranges are fine and the key to success is frequent milestones; as we learn more about the problem domain and the technology we are using, the more accurate our estimates. But most organizations take a random guess (with, I’d say, a wind’s spittle of support) and turn that into a concrete date around which the world turns. They then ignore all the little milestones (if they track them at all) or they green shift the project status. The result is failure, though sometimes we redefine that word to mean something else entirely…

On Thursday, Charles Nutter and Thomas Enebo gave a “breakfast briefing” on JRuby. It’s a good thing Charlie had forwarded the information on to the RUM list because otherwise I for one never would have found it - when someone at work asked about it, Google was fruitless. Anyway, despite the quiet nature of the advertising, there was a decent sized crowd including a couple of old friends.

While I’ve seen the JRuby/Swing demo several times now it never ceases to impress me. The lads have been quite busy and it’s clear their move to Sun has really helped them move their work along. The “schedule” for the next few months is pretty aggressive: February includes Rails 1.2.1 support, running Rails in GlassFish and a public release of the *outstanding* Ruby support that Tor Norby has been baking into NetBeans. Seriously, I think NetBeans will be a force in the Rails/Ruby editor market - it’s very impressive. And don’t get me started about how slick it will be to deploy a Rails app to a Java web server!

Now I know that last line will probably cause a few of the Rails faithful to yack up their favorite caffeinated beverage but for many, I think it could become the deployment option of choice (for a framework that makes so many things so easy…deployment still leaves something to be desired). Of course it will also break down some of the barriers that slows Rails adoption in certain settings though I suspect some developers would sooner have their MacBook Pro sent through a trash compactor than deploy a Rails app to say, WebSphere (hmm, there might be quite a few Java programmers that don’t particularly relish working with WAS).

Anyway, Charlie and Tom are looking at March as the last “pre 1.0″ release with April earmarked for some heavy bug fixing. Oddly they think they’ll have a big announcement in early May (can’t imagine why). JRuby should do an awful lot to make Rails a first class framework in the Java space and may actually stem a bit of the “brain drain” some companies are experiencing. Look to see more and more interest in Rake and migrations in the Java space too…

While I’m sure there are those that think Ruby on the JVM is heretical, JRuby is positioned to add even more fuel to the fire. If Rails made it OK to look at dynamic languages, JRuby is practically going to make it mandatory.

If you haven’t read Chad Fowler’s “My Job Went to India“, do so now. Like many of my peers, I’m wondering what will become of our industry as more and more work moves to countries with lower labor costs (I’ll leave out an obligatory analysis of the increased communication costs that often offset the cheaper wages). Anyway, Chad’s book offers some great advice on how to lessen the likelihood that *your* job will find it’s way to Mumbai.

One way to avoid the outsource machine is simple - supply and demand. Rather than polishing commodity skills, spend your personal development effort on technologies that the major off shore houses aren’t looking at yet (cough, Ruby, cough). It may seem a bit counterintuitive (like the long tail concept) but being fluent in a niche like Lisp could actually make you more employable than being yet another ASP guy. Not sure what to focus on? Take a look at Google Trends…

A very wise man asked me the other night how I cost justified spending my own hard earned cash on Rails training and I replied that I see it as an investment. I still earn the majority of my income on Java work but I realize that our industry changes every day - staying ahead of that keeps me employable.

So, people that know me realize I have a thing for quotes (see those from RailsConf as well as NFJS local edition). While there weren’t a ton of memorable quips from my recent experience at Pragmatic Studio (see Day 0, Day 1, Day 2 and Day 3) there were a couple that I had to share. Again these are largely paraphrases but I think I’ve captured the gist.

This exchange occurred when I asked Mike how he was “hiding” his Keynote deck while in play mode (i.e., switching back to the desktop without hitting escape):

Mike: “Just hit H - one of the things Dave taught me.”

me: “The list would be long”

Mike: “The things I learned from Dave… ”

Dave: “A through H - that was H.”

After trying app.methods in script console… Mike said:

“Try app.taguri..oh wait, that’s just missing the underscore, should be tag_uri, I thought that was something to do with Sushi, never mind.”

That’s not to say there weren’t other interesting moments during the class ;)…but those were the ones I felt like sharing!

Well, we ended with a bang! The morning started off with an Ajax lab (right up my alley) and I just have to say…Rails makes Ajax about as easy as it gets (hmm, I’m sensing a theme here). I especially like the fact that I can quickly get an app working, add in Ajax, and (with almost zero effort) have a degradable system. Oh, and RJS is just slick though it did make me question my opinions of GWT. Unlike a couple of my coworkers, GWT doesn’t make me swoon - don’t get me wrong, I think it’s neat as all get out I’m just not ready to jump on the bandwagon. But after playing around with RJS I might have to reconsider.

Most of today was a blur - we covered a lot of topics at a mile a minute. I think routes (especially named routes) are extremely cool and considering my new role at work the support for testing is just top notch. I asked a few questions about test infecting organizations and I’ve got some great notes about testing in general. The rest of the day included talk of REST, hooks and filters and caching finishing off with a discussion on deployment.

All in all I was quite happy with the training. A faster pace would have been good, perhaps a few more labs, but there is a limit to what can be covered in three days with a mixed audience. I suspect the Advanced Studio would be fantastic and I’m really thinking a Rails Edge would be useful (perhaps more so than Rails Conf…but that’ll be a tough call). I’m happy to call myself an alumni of the Studio - as expected Mike and Dave are great - if you need Rails training, I’d highly recommend Prag Studio!

As expected, things went up a notch today - we pretty much did labs from dawn till dusk. I wouldn’t say the fire hose was on full bore and there was only one lab that I didn’t manage to finish but we definitely covered some ground. The class is still following AWR pretty closely but I do appreciate the little tips and tricks Mike and Dave share as they walk through the exercises. More impressive is the live coding - I realize I’ll need to do more of this next year on the NFJS tour but it never ceases to amaze me how much Rails does with so little code.

The concepts are definitely starting to sink in and certain aspects are becoming more normal to me. Still, there’s a fair amount of magic..but I feel more prepared (and motivated) to dive into the source. Partials seem like a great idea and the ability to pass a hash of parms into the constructor of an ActiveRecorder subclass is just brilliant. Seriously, so much of this stuff is so easy it just feels like stealing. And all the time I’ve spent building plumbing in Java…sigh. Oh and I’m still getting a kick out of the local weather guys and how they define cold - when I checked the weather back home this morning, it was 0 so these “lows” in the 20s just don’t impress me. Big chill indeed…bone chilling. Yeah.

Tomorrow will be Ajax day plus the future of Rails - should be interesting!

Update: OK, so Joe and I went to get a cup of coffee this morning and I have to admit…with the windchill, it *was* pretty nippy. Not as cold as home but it got my attention.

And it begins! First off, they’ve got the big three: wifi, power, and caffeine, you can tell Mike and Dave have done this before Day one is a half day Ruby tutorial and then what I’d describe as roughly the first seven chapters of AWR. The crowd is a little quiet but all in all some good questions. So far the real value is hearing Dave and Mike pipe in with tips and tricks. No matter how many times I see how fast you can get basic CRUD up with Rails, it never stops impressing me.

All in all, nothing too revolutionary today but I suspect tomorrow (again, this will be posted after the fact!) will really get things started. One thing I have to say - I really like the pace of the South. We’ve eaten out a couple of times now and each time they really stressed “y’all just hang around as long as you like.” I’m starting to understand what Southern hospitality is all about.

I’ve been a big fan of the Prags since I read their first book The Pragmatic Programmer so when they started up the Pragmatic Studio earlier this year I knew I’d have to partake. As soon as I saw the December show in Atlanta, I pulled the trigger! I did contemplate switching to the Twin Cities show - but going to the ATL actually saves me travel time (seriously) and gives me an excuse to hang around with an old friend. The trip down was pretty easy though the woman in the seat next to me clearly was uneasy about flying…and it rubbed off on me. I’ve never been too anxious about flying (I understand the odds) but sure felt like I was channeling some of her emotions.

Let’s see, what else. For the first time ever I took a cab to the airport - that was interesting. I’m used to taking cabs/shuttles once I *arrive* but this was new. My cabbie was a transplant from the Bay area so we discussed the futility that is being a football fan… The flight was uneventful (yeah). I was pretty amazed at how large Atlanta International is (next time I’m going to take the tram) and the hotel is fine - huge though. The weather is “cold” by Georgia standards (I loved the comment this morning on the news: “pipes could freeze and bring in the pets”) but for Joe and I it’s quite pleasant. Heck, back home we’re seeing highs in the single digits - here they complain about getting into the teens…for the morning low. Yeah. Tomorrow (well this will be in the past by the time I post) should be great - I’m really looking forward to immersing myself in Rails for three days!

I began my collegiate career as a Chemistry major - the shinny new chem center combined with the fact that a degree in Computer Science required more than a minor in math got me thinking that mixing known carcinogens was as good a way as any to spend four years. But then I hit O chem and the powers that be reduced the math content significantly so off I went to the land of compilers. Needless to say, I took a rather, ahh unique, path through the major and while the finer points of circuit design have been lost to the ether, bits of my chemistry training still stick. For some reason, I still remember when the concepts of entropy and enthalpy were introduced during that first year chem class…

Needless to say, I was taken in by Neal Ford’s Entropic Software post. Neal uses an interesting example to discuss the similarities between the technical definitions of entropy and information to support his central tenant that “software breeds entropy”. He continues by comparing the design of Unix and it’s history of “mini languages” to Windows and its (I’ll say it - clunky) approach to interoperating (I couldn’t help but think of Martin Fowler’s keynote from RailsConf along with his discussion of DSLs). The moral of the story? Keep it simple…ah you know the rest.

The nature of the universe is towards disorder (told you I remembered something from that chem class) and I have to agree with Neal that software tends towards complexity. Some of this is our fault - for whatever reason people in this line of work reallllly like complexity (often for it’s own sake) but the ephemeral nature of software doesn’t help (c’mon how many of us have added just “one more feature” since it wouldn’t be _that_ hard). Though he doesn’t explicitly mention it (until the comments) part of why Rails rocks is that it adheres so strongly to the principle of simplicity.

While I certainly don’t know *what* technology will be the king in five years (even if I did I’d keep it quiet until I was able to write the definitive book on the subject) it is clear that Rails has had a major impact on how we write software. As I mentioned in my JavaOne recap, everyone is trying to “prove” that their approach is just as easy as Rails (or they try point out how it isn’t enterprisey enough). Neal’s dead right - software wants to be complex and it takes a concentrated effort by engaged developers to do that. Let’s hope more of us are inspired by the diligence of the Rails team towards this end.