notkeepingitreal.com: Philosophy On Software Releases

Philosophy On Software Releases

Kevin — Sun, 21 May 2006 17:33:00 -0600

I believe that releasing new software when it is done¹, and immediately when it is done, is a tremendous boon to the developer (and by definition the customer, unless you happen to be adding features the customer doesn’t want). I’ve dreamed about this a lot, and advocated for daily web rollouts at work for months, so naturally I was pleased to find that Paul Graham has argued this point in his essay, The Other Road Ahead.

There seems to be much opposition to this idea in the software arena. Releases are often no fun, and many seem to think that releases are inherently difficult, time-intensive and error-prone – and should therefore be minimized. Some say that customers need to be conditioned not to expect what they want now. There is definitely truth in this. But for all of the reasons releases are tricky, I believe they should be done more and more incrementally.

Releases are difficult

Sure. Releases will be difficult as long as:

People assume that they happen only infrequently
There is a perception that it just isn’t worth the effort to make them work the way they should

If I used the vim text editor once a week, I wouldn’t bother creating/learning the cutesy shortcuts. Institute a continuous release policy and the process will improve guaranteed.

Releases are time-intensive

Yes, if there are many new features, QA can become a long and uncertain process. And when a bug is found, the amount of time that has passed since the code was written correlates fairly directly to the time that will be needed to fix the bug.

Releases are error-prone

Certainly, managing the complexities and anticipating the interactions between features of a large release is an unenviable task.

So if new code is ready, or if a feature the customer wants is finished to everyone’s satisfaction, I feel that there shouldn’t be a ton of hoops to jump through before the new software finds its way into production. Developers will ultimately be happier to see their creativity in finished form faster, customers will get their feature more rapidly, and potentially, delicious manna will pour down from heaven.

¹ Done, in this case, means ready for release, including any necessary testing.

"Philosophy On Software Releases" by Kevin

Sun, 21 May 2006 23:16:07 -0600

Indeed. Quality is really the goal, so if testers aren’t completely confident with the code that is going live, there cannot be a release. Creating that confidence isn’t easy, but is certainly a goal worth striving for.

Automated tests, code diffs and plain old communication can all make the process smoother. One of the all-stars on my team at work has put some time into creating a utility that does a diff of the html that is generated by the entire website, showing us exactly what pages have changed and how they have changed since the last released version. Tools like these inspire confidence in developers and testers alike, and can allow us to move naturally towards more frequent releases.

"Philosophy On Software Releases" by dstutz

Sun, 21 May 2006 22:02:11 -0600

The problem with frequent releases is that unless you can convince a tester that all your changes are trivial and very safe (and they should push you on this), they’ll feel responsible to test the whole thing again. It’s hard to isolate changes in software, so the safe thing for them to do is go through every test case again, which takes one or two days. There goes your quick rollout. I’m not sure if this is a technical problem to be fixed (GUI automation tools promises a lot but I haven’t seen them deliver), or an organizational problem (knowing exactly what code was committed there), or a trust problem (developers will take responsibility for identifying what areas they’re affecting), or what.