ntschutta.com

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.

Andy Hunt recently posted a great piece: Stage 0: Not Ready For Agile. He was all set to give a talk at a company until, well, someone discovered he was coming. Turns out the manager that contacted Andy hadn’t followed the non-existent process and instead of congratulating him or her on bringing in a well known speaker, they decided it’d be better if it could never happen again.

As stunned as I was by this, I’m not surprised. Talk is cheap - it’s easy to say you want to be (or are) agile but the proof is in the pudding. You can say you value collaboration but when there are three levels of indirection between developers and end users, that statement echos hollow.

Culture plays a huge role in how we build software; Andy lists several traits that indicate you might not quite be up to the challenge of agile. Some are fixed more readily then others but if your culture won’t support it, you’ve got your work cut out for you. Unfortunately, cultural issues don’t respond to technical solutions as Reg Braithwaite says so well with this quote:

“Cultural problems cannot be solved with technology. If you are an advocate for change, ask yourself what sort of cultural change is needed, not what sort of technical problems need to be solved.”

Changing culture is hard, but for many organizations, it’s the critical first step towards better software.

It shouldn’t be a big surprise that I prefer low ceremony agile processes to their heavyweight waterfall brethren. While I’m certainly not anti-process, I’ve spent way too much time in meetings defining how we were going to write software. Recently I wondered, do other industries spend so much time on mundane details like templates for issue logs? Perhaps they do, but I doubt the architects of the new 35W bridge spent a lot of time discussing the how they would document the plans for the new roadway.

Most companies I’ve worked for spend an awful lot of time and money on process. Much as no serious enterprise would ever consider deploying SAP or PeopleSoft without a hefty does customization, every organization wouldn’t dare to use an off the shelf process. No, it’s better if a group of people spend months coming up with the perfect approach and a set of presentations that would make Tufte weep. Despite a lot of pats on the back, I’ve yet to see this effort lead to any significant business value, yet it is a persistent part of the environments I’ve worked in.

It seems to me that most companies focus on process for one of three interrelated reasons. First off, there are a number of people in technology that, well, aren’t very technical. Some of these folks *used* to be, but many just bluffed their way into higher paying roles and well, they need things to work on. Of course not everyone needs to spend their free time brushing up on the finer points of the closures in Java, but last I checked templates don’t compile their way into working software.

Second, software projects have a nasty tendency to fail and to combat this fact, most organizations want greater control over the work. To accomplish this goal, they invent more and more process, more gates, more checkpoints. Of course it doesn’t really work that way, and the tighter they grip, the worse things get (hmm, sounds like a Star Wars quote to me.)

Project failure brings us to reason number three: plausible deniability. If (or is it when?) a project isn’t everything it can be, we can always point the finger at the process as either a point of blame (if only the process had a few more gates…) or as an example of success (as in: we’ve got a great process now…) Following the corporate standard also gives managers et al an easy out: yeah, the project failed, but we followed the all mighty process.

Don’t get me wrong, heroic software development isn’t good either. I’ve worked in manners best described as fire fighting and frankly that’s just too much stress for me (though some people I know absolutely thrive on that rush.) Like so many things, process lives on a continuum. At one end, we have absolutely nothing - hack and code, cowboy coding, whatever you want to call it. On the other end, we’ve got extremely heavyweight command and control approaches that attempt to plot out when every developer will use the bathroom.

Truth is often found between extremes and we should seek a balance. Do what’s right for your project though I’ll always favor the less is more camp. And before you spend the next few months creating the perfect process see if something off the shelf will work. Better yet, try some stuff and see what works for you - repeatedly ask yourself these two questions: what worked and what didn’t; do more of the first and less of the second and you might just find yourself on a successful project.

These days, it seems like you can’t go more than three or four websites without running into a screencast. Sure, video is all the rage on news sites but in the technical space I suspect it has something to do with their use in evangelizing Rails; how you couldn’t be impressed by the original “build a weblog in 15 minutes” is beyond me. Though I’ve yet to dig into any of the PeepCode screencasts, I’ve heard they are absolutely top notch and my friend Neal Ford has an IntelliJ show up on the No Fluff site.

Anyway, the Prags have gotten into the mix with their own take on this “new” medium. They’ve got five up at this point and I just bought the first installments of the Ruby Object Model and Metaprogramming. A couple of things have really impressed me: first, there’s no DRM. Once again, Prag shows that they trust their customers to do the right thing. In addition to iPhone ready videos, they have good old fashion QuickTime files and it’s pretty had to beat the price. Oh, one last little touch - when you visit the site (and you’re logged in) they’ve grayed out the screencasts you’ve already purchased. This may seem like a small and obvious detail but I could see a company “neglecting” that in the hopes someone might inadvertently purchase something twice.

I love podcasts and I’ll always be surrounded by books, but somethings are just best conveyed via video. These days we’ve got a ton of great educational options, so if you’re looking to learn something new or brush up on an old favorite, see if someone has a screencast. Heck, with today’s tools, you could create your own!

Surfing my blog reader the other day, I couldn’t help but react to the news about Microsoft bringing ads to the Zune. Boy, that ought to *really* help sales. Reg Braithwaite has commented on this already but I’ve really got to wonder how long it’ll take companies to figure out that putting the customer first works. I think Reg hits on it - we aren’t the target market here, shareholders or marketing departments are. Clearly the music industry doesn’t get it but anyone want to wager on the likelihood of ads on an iPod? Only one US air carrier posted a profit in the first quarter and they consider themselves first and foremost a customer service organization. Huh. Wonder if there’s a connect there? Nah, couldn’t be.

My friends Neal Ford and Stu Halloway have talked about yak shaving before but a couple of weeks back Dilbert put the concept into comic form:

Classic yak shaving there

Like pretty much any office with more than 3 people, we struggle with the ephemeral concept of knowledge management. Now, this takes the guise of everything from cultural lore to more basic issues like where is the latest version of the FooBaz document but the moral of the story is simple: we’re still trying to find the right approach. We have a corporate product that hardly anyone uses because it’s slow, the search is horrid, and it has very rigid ideas around who can post what where.

Recently, a number of teams have started to use a different product, one they are finding to be far more useful then the corporate standard. Though it isn’t officially supported, it’s gaining quite a bit of traction throughout the organization. Imagine my surprise when an IS wide email goes out saying, in essence, that everyone should STOP using the product that’s working and contact the head of the crappy product team immediately so they can “migrate you over” to the “standard.” In other words, cease doing the thing that’s working, not “wow, we’ll fast track the adoption of this new tool since it’s serving such a vital need.” Makes perfect sense.

As I was reading the email, I thought of St. John’s (Go Johnnies!). Anyway, around the time my father was in school, they built the tundra dorms - named as such for the large open space between the bulk of campus and the dorms. Anyway, when they built the tundra dorms, they didn’t put in sidewalks right away, they waited until the students had worn paths and just paved those. Rather then guess what route residents would take, they let the property emerge. Needless to say, this approach worked pretty darn well.

The parallel here is pretty obvious - right or wrong, the “students” are wearing a path towards this new tool. Now I’m sure we can argue that the corporate standard can do “everything the new tool can do and so much more”, but the crowd has spoken. Instead of using scare tactics to keep people from using it, perhaps the bureaucracy would be better served by following the herd.