Traditionally, we’ve approached a launch date as a mission-critical point in time when software must be final. There’s no going back.

For buildings and structures, that’s essential. In software, the metaphor made sense at one time too. When we shipped software on floppy disks and CDs, things had to be just right. There were huge cost and time implications for bugs. Projects were delayed for the sake of getting it perfect or for the sake of shoving in a new feature. I’ll talk about what that does for morale in the next chapter.

Today, web-based applications aren’t launched; they’re uploaded, released, and pushed. Software lives and matures over time.

Once we’ve launched, iterations 2, 3, and 20 can come a few days or even a few hours later. Even the concept of formal version releases of software is antiquated. It made sense in the bygone days of shipping software on disk.

Today, we continuously integrate and constantly iterate. Unlike the auto industry, there’s no need for mass recall. Today, a critical bug can be patched, tested, and deployed immediately. It’s not version 2.0 anymore. It’s version 2.0.12931. Or, it’s simply today’s version. Is anyone in the public eye really keeping track anymore?

Society is growing accustomed to iteration too. Did you see the new image gallery on Facebook? Did you see Google’s new autosuggest feature? How about Twitter’s new layout? Nobody warned us with a monthlong advertising campaign. New changes just appear now. IMVU,^[2] a popular 3D-chat application, boasts more than 100 million registered users, and it ships releases 50 times a day.

In today’s landscape, the initial launch shouldn’t feel like the end-all and be-all like it once did or still does in many other industries. It’s just one of hundreds (if not thousands) of mini-releases that take place during the life span of software. Keeping that perspective can relieve the mental pressure of launching software.

Unfortunately, this mentality can be easily abused. Don’t use this change of construct as an excuse for being lazy or leaving loose ends untied. The launch of an application should be very, very good before others have at it. The big things need to be right. Proper security needs to be in place. But the small stuff, the stuff that is OK to fix afterward, shouldn’t keep you from releasing software. You’ll be surprised how often things you thought were important when you launched suddenly aren’t...now that it’s out there.

You still ought to celebrate when software launches. Take your team out to that fancy dinner. But don’t spend all your emotional currency on just the wedding. There’s an entire relationship you’ll have with software afterward. There’s time to make adjustments, add a family of new features, and right wrongs.

Launch is just another point in software’s life. Not the end-all and be-all.