Make small incremental changes.

Avoid massive releases.

The larger the release, the more bugs there will be. When you only release software a couple times a year, you have bugs on top of bugs and under bugs and hidden by other bugs.

A large release tends to have many different classes changing as well as many new dependencies and interconnections. The complexity and chance for things to go wrong increases geometrically, not linearly, as more parts are added. Thus, in a large release, there will always be several things wrong.

Another issue with giant releases that happen rarely is that the business requirements have probably changed during this time. So what you are delivering may no longer be what is desired. This reduces you ability to deliver working software and add business value. And if you’re not doing that, then what are you doing?

On the other hand, in a tiny release, sometimes very little is changing. And because the change is small, it’s carefully tested, and has a low chance of being wrong.

And with short, rapid releases, you can be a lot more agile, and respond to change instantly. Your business people will love you for that.

Ideally, you should have a series of frequent, tiny releases. In some organizations, they are able to push to production several times a day. To get there, you need to master unit testing, integration testing, continuous integration and continuous deployment.

You need robots that will automate all of the work that goes into a release.

Robots are the future.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: