Ship Software With Value

Tim Barcz — Tue, 29 Sep 2009 18:49:24 GMT

The blogosphere has gone a bit crazy the last few days with posts responding to Joel Spolsky’s latest article about "The Duct Tape Programmer". Bloggers everywhere are tossing their two cents in and saying what parts of Joel's post was good and what wasn't good. Once noticeable trend is that many have jumped on the "just ship it" bandwagon.

There’s a quote mentioned by Jamie Zawinski in the article:

“Yeah,” he says, “At the end of the day, ship the f---ing thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

I don't know Jamie and I imagine the context that the comment was made in was based around some pre-existing level of candor with the person he was speaking. We really don’t know what “…ship the f---ing thing” means in the context of that conversation and what level of quality is expected in that scenario. I would agree with Joel/Jamie that shipping products is important and that often developers (myself included) run the risk of becoming too entrenched in a design or beauty and all too easily miss the point of developing software...which is to ship a product that adds value. However...”shipping” is only part of the picture. As someone responsible for the value of the product my team ships, I’m keenly aware of what affects shipping early can do (both the positive and negative).

I'm reading a lot where people say "just ship it" but I've been part of teams where shipping too soon costs more money in the long run (and sometimes not even “the long run” but a few days/weeks down the road). These pro “ship it” bloggers surely must be talking about non-critical business systems when we say "just ship it"; would you want to ride on a plane where the flight control systems were sent out with bugs? Even a measly 1% failure rate of airplane system is unacceptable and is enormously expensive both in dollars and reputation for an airline.

The point is that shipping is the point but not the whole point, it's only one aspect of a well delivered software product. Shipping software with value is the point. Ship too soon with bugs and the value gained by shipping is potentially lost. Conversely shipping late provides no value at all. Neither lobbing a piece of crap over the wall at your customers early, nor refactoring your code till it shines is the point, neither should be considered a success. There’s a sweet spot that you need to find. Keep in close contact with your customer, if you pay attention they’ll let you know when you’ve crossed into either extreme.

The Tortoise and the Hare

Tim Barcz — Mon, 11 Aug 2008 17:13:00 GMT

We're all familiar with the Aesop's fable of the tortoise and the hare. In the story, the hare, who is in every way is faster than the tortoise, loses a race to the tortoise. The main principle of the story is that slow and steady wins the race.

In my development I am shooting to be a tortoise, really I am. Read on and let me explain.

A few weeks ago I got some evil glares when I suggested at our .NET user group meeting that in enterprise systems that you don't have time not to test. It's a common hurdle for those new to testing to say, "I don't have time to write tests." Let's face it, we're all busy, that excuse is tired. As an agile and lean practitioner I seek out ways to improve velocity and reduce waste, not take my already busy schedule and cram in another tool for the sake of another tool. While writing tests does slow me down, it brings on tortoise like speed, which I would argue is a good thing. Writing unit tests is one tool that provide me the ability to keep a more consistent velocity over the course of development. Without tests I can surely write things faster, the problem arises as the codebase grows and each new feature or fix takes increasingly more time. Eventually, even simple requests become arduous to implement. Slowly you see your velocity come to a crawl.

It's an insidious cycle that I've seen before and am currently in the throes of; an application is built from scratch implementing everything the business requires. The application is enhanced and bolted on to, until you realize that you could move much faster if you could start from scratch. You make pleas to your boss and explain how much productivity would improve if you could shed the hideous code base. One day he gives in, you rejoice and you make the leap, start from scratch, breathing a sigh of relief at how easy implementing the features are all the while reminiscing about the old framework and how poorly it was written. And now that the application is rewritten from scratch the cycle, unless you were aware of it all the while, starts again.

You see, no one sets out to write crap code. People do the best they can with the knowledge they have. Code, following the second law of thermodynamics, tends towards chaos over time. With unit tests in place I can refactor with more confidence and implement new features without the fear of breaking existing code. If you have the ability to refactor, new code is no longer "bolted on" but rather "grafted in" becoming part of the system. With a solid framework with tests in place you can much better stop the cycle of rewrites. Quickly writing applications that degrade is the way of the hare. Developing purposefully using unit tests causes me to be slow in the short run, but over the life of the application comes out far ahead. In that way, I strive to be the tortoise.

Tim Barcz : Agile, Rant

Ship Software With Value

The Tortoise and the Hare