ntschutta.com

I’m a bit late in announcing this, but along with fellow Fluff Talkers Ken Sipe, Andy Glover and Venkat Subramaniam, I’ll be speaking at CodeMash 2009 this January! I’ll be talking about Dynamic Languages and the JVM as well as Test Infecting the Legacy Organization. The show is sold out and I’ve got to admit the idea of hanging out at a water park in the middle of winter sounds darn appealing! Hope to see you there!

Moving is one of those things that (hopefully) we don’t have to do that often; it takes a lot of time and energy plus it is a real pain in the behind. But, every so often we have to pick up stakes and when we do, we’re usually amazed at just how much stuff we’ve accumulated. This is particularly obvious when you’re in college – I distinctly remember packing for the summer wondering how the heck I’d get it all home; I’d only needed one trip up in the fall, why would I need so many in the spring? And then it would occur to me. I’d made several trips during the year, where I’d innocently bring one or two items, maybe even a bag of stuff. Over time, the bits built up.

Software works the same way. Over time, a feature is added here, refined there and before you know you’ve got a mature product. And a messy codebase. Eventually this will lead to a rewrite often accompanied by a technology change of some sort or another (this time we’ll get it right!) Rewrites can be pretty good projects but they’re not without their perils. For one, customers usually won’t spend much time defining requirements. I’ve often heard “it needs to work just like the old system…only better” with better being some vague hand-waving around a pet peeve or two.

In addition to vague requirements, rewrites tend to suffer from estimation fatigue. Customers are convinced that they need to have all of the old system’s functionality (plus all the new doodads they thought up over the last 20 plus years) and they need to have it *right now*. Like my college aged self in the spring, many customers loose site of the gradual build up in functionality of the existing systems and many will insist that the new one won’t be useful until it fully replicates the old. That last statement doesn’t hold water but good luck convincing someone that feels otherwise; the old system didn’t have all its features on day one either but that’s not the anchor point for the people asking for the new system.

Rewrites are an excellent opportunity to do some process reengineering and, if done right, usually results in a vastly improved workflow. Of course this requires us to look past the angry monkeys in our systems and think of how things could be rather than how they currently are. This step is often skipped though, and we simply end up further codifying the legacy approach. But at least it’s in a new technology stack.

Whenever I’ve moved, I’ve used it as an excuse to prune some of the stuff I’ve accumulated over the years (hint – look for boxes that you didn’t unpack the last time you relocated.) When you encounter a rewrite, see if you can’t do the same, try to eliminate some features, reports or screens. Most customers will scream bloody murder when you suggest clipping things, but half a product beats half-assed any day of the week. Writing code is like writing prose, the important bits are the ones you cut – applying this approach leaves you with a smaller codebase that’s easier to maintain. Besides, the code we don’t write is bug free.

So, next time you’re staring a rewrite in the face, see if you can’t cut some of the detritus; odds are you don’t really need all 283 “views.” But instead of using words like eliminate, try defer – most customers will see that as less scary. Be sure to remind them that you can always add that in later when you have a better sense of what you actually need. Odds are those “must haves” will slip quietly to the bottom of the backlog.

Today we learned something important, the NTSB announced the results of their investigation of the the 35W bridge collapse. Turns out it was a design flaw – some gusset plates weren’t quite up to snuff. As a result of this tragedy, bridges of similar design will undergo much needed scrutiny and we won’t see these types of designs in the future. Heck, by now engineering textbooks have probably already been updated.

Contrast this with the average failing software project. Maybe this is a bit of stretch (much like the bridge construction metaphor) especially considering that few software failures result in the loss of human life. But when was the last time anyone published a report about what went wrong with a multimillion dollar software collapse? No, we bury our mistakes (near Jimmy Hoffa) and pretend that the next time, when we do it JUST like we did it this time, it will work. It’d be too difficult to admit we did something wrong, even in the “safe” confines of our own organizations protected with lengthy NDAs.

Retrospectives are a vital part of creating better software but to be effective it requires a level of maturity that few organizations posses. Taking an honest look back at what happened, what went well and what went wrong leads to better results but only if you can discuss the project/increment/whatever openly and more importantly change how you do things. Life is full of constant adjustments, why should software projects be any different?

I spent my formative years on a small hobby farm. In addition to witnessing first hand the whole circle of life thing, I learned just how versatile duct tape and bailing twine can be. Of course I also learned that those temporary solutions rarely stood the test of time – or a stiff wind. Still, in a pinch, the quick and dirty solution isn’t always wrong provided you understand the consequences.

In software, we’re often pressed to slap something together, to hit a date, to use duct tape and bailing twine. Sometimes that is absolutely the right thing to do – the merger closes on the 1st, booking revenue requires the product to be released in the current fiscal year or marketing needs a demo for a key conference. Like our temporary solutions on the farm though, these improvised systems aren’t meant for the long term (or more than three users.)

While no one seems surprised when a quickly constructed lean-to falls over after a few days, people are stunned when jerry-built software isn’t up to the task. Some of that is the nature of software – people can *see* the temporary nature of our quick fix in the real world, but it takes a developer to really appreciate the craptacular nature of some code.

The problem isn’t (necessarily) with the quick fix, its expecting too much of that rushed work. Well, that and deciding that dates are far more important than, you know, quality. Many seem to forget the cost of releasing a bad product. Best case results in a pulled release or paradoxically another quick fix; worst case is a pulled product or lost customers.

So yes, sometimes we should cut some corners but we need to do so with our eyes wide open. And we need to make sure our customers understand the consequences of doing so.

My friend Brian Sletten sent me a link to this video and I had to pass it along…to all you business types out there, don’t forget to give your developer a hug. Enjoy!

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.

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.