In the Spotlight - Nathaniel Schutta

I remember the first time I flew for business - I was working for a small consulting company and I was heading to Chicago for a few days of training. I was pretty excited to be on the road (and on expense account) but I was more than a little paranoid about loosing my laptop. Turns out I was right be be concerned: nearly a quarter million go missing each year. I’ve been traveling more then last couple of years but there’s still a little gulp when I put my silver beauty on the old conveyor belt - so far so good (knock on wood) but I just hate having to take my laptop out of my bag along with my oh so dangerous liquids.

Driving home from Fourth of July fireworks, MPR had a blurb on this topic (Future Tense has a wrap up in this podcast.) The TSA is proposing the ultimate laptop bag though the usefulness to travelers is questionable. I doubt I’d purchase one but I have admit, it would ease my mind if I didn’t have to pull my MacBook Pro out of its safe, snug little case each time I went through security…

I don’t get to go to quite as many conferences as I’d like but luckily more and more organizers are putting talks on-line or releasing interviews and other useful tidbits. YouTube is home to a bunch of Google Tech Talks and the videos from Google I/O are up (take a look at Steve Yegge’s Server-side JavaScript on the Java Virtual Machine.) I’m a huge fan of TED - Sir Ken Robinson’s talk on education has been on my iPhone since day one and is a much watch.

Anyway, Glenn Vanderburg recently posted a link to a conversation about beautiful code recorded at JAOO. The 20-ish minute chat is full of lots of nuggets including a Thomas Aquinas reference. Software is much more art than engineering, something that is often lost of the non-technical and creativity is (rightfully) getting more attention these days. I found myself nodding along throughout, well worth a watch.

Last year’s Rich Web Experience was a big hit with some of the top Ajax/JavaScript/Design experts around. This year we’ve got not one but two chances to get your web groove on! With fantastic speakers like Molly Holzschlag, Douglas Crockford, Neal Ford, Stuart Halloway and David Verba, you’re sure to learn a ton. As usual, you’ll get technically focused 90 minute sessions with tons of speaker contact, all meals included, a great party, and it’s hard to beat the swag. Early bird registration ends August 15th and attendance is capped so don’t dawdle. I’ll be speaking at both shows and I’m really looking forward to it - hope to see you there!

Clearly I’ve kicked off a trend - one day, I post about process, a few days later Reg Braithwaite coins a new term and the Daily WTF posts an ode to process . OK, I’ve only got three readers so I know it’s all just a big fat coincidence but still! Process theatre really does capture the notion perfectly; pointy haired bosses believe more templates, meetings and blind adherence to methodology are the answer to failing projects. Of course when you remove all decision making from the hands of sentient beings, you get a lost workday instead of someone just hitting the spacebar.

I’m not anti-process; you’ve got to have some framework to hang your work on. I plain can’t stand dogma though and I thoroughly believe you need to test your processes just as much as you test your code. Is this document/meeting/hurdle saving us money? Resulting in better projects? Happier customers? Whatever the raison d’être, we should make sure it’s actually delivering. Do more of what works, less of what doesn’t. Rinse and repeat.

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.