ntschutta.com

Recently, I sat through some vendor presentations and while I won’t name names, I just have to say: learn to give better talks. If I had a dime for every speaker that said some variation of “if you can read this slide” I’d be playing *a lot* more golf. In what I can only call yet another example of how Scott Adams hides out in my office, our friend Wally shows off a slide that I think I saw earlier this week.

Oh, and saying “I hope none of you are color blind” isn’t all that funny. Why do people feel compelled to jam twenty things onto one slide? Are the little bits of electrons that costly? I for one have a rather unique presenting style and while my slides don’t do much as takeaways, I have yet to hear someone say they weren’t spot on for presenting. And whatever you do, make an extra pass through your deck for typos; some may still slip through, but trust me, you’re judged on them.

If you find yourself doing any amount of presenting, I beg you to attend a couple of Toastmasters meetings (the damn bell will cure you of filler words – ahs, ums, you knows – right quick.) Spend some quality time on Garr Reynolds’ Presentation Zen, help us all and absorb his lessons. Oh, and if you’re sending people out into the field to represent your company, do us all a favor and send someone with passion. The last vendor talk I sat through nearly put me (and most of the attendees) to sleep and I assure you, that doesn’t improve your odds of a sale.

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!