Archive for the ‘Development’ Category

The Importance of Retrospectives

November 14th, 2008 No comments

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?

Categories: Agile, Development, Software Tags:

Duct Tape and Bailing Twine

September 18th, 2008 No comments

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.

Categories: Development, Software Tags:

Hug a Developer

August 31st, 2008 21 comments

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!

Categories: Development, Software Tags:

Beautiful Code

July 15th, 2008 No comments

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.

Categories: Development, Software Tags:

Ode to Process

July 5th, 2008 No comments

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.

Categories: Agile, Development, Software Tags:


July 2nd, 2008 No comments

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.

Categories: Agile, Development, Rails, Software Tags:

Culture Kills

June 21st, 2008 No comments

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.

Categories: Agile, Development, Rants, Software Tags:

The Purpose of Process

June 21st, 2008 No comments

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.

Categories: Agile, Development, Rants, Software Tags:


June 15th, 2008 No comments

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!

Categories: Development, Software Tags:

Dilbert on Yak Shaving

May 23rd, 2008 No comments

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:

Yak Shaving

Classic yak shaving there ;)

Categories: Development, Off Topic Tags: