.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Tuesday, January 17, 2006

Software Ideals.

How many times in your life have you ever thought to yourself, "I'll just slap this together now, and fix it later." I'm not sure what it is about the brain's wiring that makes us think that somehow tomorrow we'll be much less busy, have much more money and more energy to do the things that we either don't have the energy for today, don't have the money for, or just don't want to do. Only in hind-sight, and apparently after quite a bit of experience do you learn it's just not true. Every day I wake up, there seems to be even more to do, with less money, and it's needed faster than ever - not the other way around. So in reality, that "tomorrow" we’re thinking about (the one with all the extra time, energy and money) never comes. So things never get fixed/patched/improved like we thought they would. After a long while, you look back at your work and realize all you've done was produce half-assed work always thinking you'd fix it "tomorrow". And here we were thinking we were just making those tough decisions, the compromises, to live to fight another day.

This realization begs a change in behavior. If in fact tomorrow isn't going to be any easier than today (and you're actually going to realize there are 5 more things you need to do on top of your current to-do list), then there's no time like the present to patch that hole, fix that bug, or do those sit-ups that you aren't going to feel like doing tomorrow any more than you feel like doing today.

"There's no time like the present." "Do it right the first time." "Anything worth doing is worth doing right." "Good enough, isn't." "Relentless improvement." "Whatever you're doing, do it better than the next guy." "Do a smaller number of things, but do them better."

These are phrases that have been rolling around in my brain for a while now. Over the last year I've been building a software project management application that will be released this year (not a small endeavor). My company's mission (Devshop.com) is to help teams produce better software. During this time, I've had a chance to re-evaluate many of the patterns and habits I've developed (and witnessed) over the years, in producing software for the companies I've worked for. One of the great things about striking out on your own is that you get to chose how you're going to "follow" the good patterns, and how you're going to break the mold and do things differently ("lead the pack").

We all know that no matter what we're doing, there's always going to be some kind of time pressure on us. I personally have always placed extra emphasis on not only getting a job done, but hitting your target date as well. In truth, looking back I've made some of those common decisions (mistakes) like cutting testing, cutting documentation, cutting user interface design all to hit what seems like a fairly arbitrary deadline, so that we can say we made the release date.

It just doesn't make good business sense. Not that you should keep your application in development forever until it's perfect – we've all heard the stories about applications that never got off the drawing board. But I'm assuming you have a set of reasonably fixed requirements. Those stories about applications that never saw the light of day got that way because of never-ending requirements change – not because some perfectionist didn’t want to release their code because it wasn't perfect yet. So that's really a different issue.

I think that the moral of that old story, "We need to ship at some point otherwise the software will never get off the drawing board" is out-dated. For the last 10 years at least, the trend has been to release software far too early (with not enough testing, refinement and design) rather than after too much fine tuning. Look at the state of software today. It's buggy. Slapped together. Rushed. Do not fear taking the extra time to get it right – fear shipping sloppy products. There's enough evidence out there that the "first mover" advantage is a myth. Too many times a "fast follower" has come along with a better implementation and kicked the inventor's butt with his own invention. All you accomplish by shipping a pre-mature product with a great idea is give the idea away to your competition at a time when you have a poor implementation of it - a bad idea. Getting the customer "first" is really important when it's nearly impossible to get them to switch later - but switching software is easy. Focus on keeping them once you get them, rather than just getting them first.

I've heard it said that the development phase of a product's life cycle is a small one-time cost (say, for one particular release), whereas support and maintenance is a large recurring cost. It's true. If you look at established software companies, their product development expenses are often far less than any other department – marketing, sales, support, operations... That's one of the great things about the software biz. If done right, you can spend (relatively) a little to build a great product, then sell it a billion times and make a pile of money. At least that's what everyone is aiming for. But notice I said "great" product. That's the hard part.

"Great" products aren't rushed, slapped together, ill-designed or buggy. They are the result of a steadfast belief that quality comes first. Not just quality only in the quantitative bug-count sort of way, but in terms of design, user experience and ability to solve the original problem. Great products aren't just a bag of features or a brochure as long as your arm. They are an "elegant" solution to a problem.

I think that we as software producers need to stop deluding ourselves that we'll fix it tomorrow, or that hitting a release date is the #1 goal of a software team. Tomorrow will never come (at least the tomorrow we're thinking about) and a timeline-over-quality approach leads to weak products.

I was recently faced with a business decision about when to launch my own product, and with what feature set. The choice was to launch sooner (a Quarter at least) with a much reduced feature set (that solved the problem "less well" than the original design) or to stay the course and deliver on the original mission. Giving up short-term revenue is not an easy choice to make for anyone. But ultimately I believe that it's the substantially better product that is going to win, not hitting the market 3 to 5 months sooner.

This decision has caused me adopt different habits. Like, when you find a bug, stop what you're doing and fix it now. It won't be easier or cheaper to fix later – it'll be harder and more expensive (time and money), when you've lopped another 20% of code on top of your application – or after it hits the street and starts affecting customers. My personal commitment, is to ship with "zero known bugs". Not that I and my customers won't find some after release, like with any software product, but I'm not going to use a "known issues" list as a crutch to ship early.

The need to stick to your ideals and put quality first is even more important for small companies. Maybe if you have a monopoly you can get away with bad customer service and poor quality products, because customers have nowhere else to go. But if you're an up-and-comer looking for an angle to compete on, make it quality. It's something that people sacrifice far too often and can give you a leg-up.