Neil Mix

It’s amazing how much the Internet has changed the software development process. There’s now an entire generation of techies (including me) who were indoctrinated into the art of building software with a casual release process. Back in the old days, releasing software was anything but casual, because you’d put the bits in a box and put them on shelves to sit and wait for someone to buy them. But the web brings the customer to the software every time they use it, which makes traditional software release go all topsy-turvy.

It all starts with cost structure: in the ancient world when there was no Internet, how did you fix a product defect after it was released? Well, you put the fix on floppy disks and mail it out to customers. As you can imagine, that’s pretty costly. So if you release a product with a serious bug, you’re going to chew up a ton of money paying for what turns out to be a product recall. You know, like when a car has a safety defect and you take it into the dealer to get fixed. It doesn’t take much mental effort to realize that in this world shipping defects results in an unprofitable business. And thus software companies (the ones that succeeded, anyway) learned to be very careful when releasing product. This is where the term “GM release” comes from — the “Gold Master” CD on which the software was written to be mass-duplicated. Once the bits are written, they don’t get unwritten.

Along comes the Internet and its new-fangled web-apps, and suddenly it costs almost nothing to release a bug fix. That one little variable changes, and now the software development process is entirely different. The strict no-risk release process now loosens up a little, becomes more casual. Pretty soon, the “throw it against the wall” mantra becomes popular, and people start intentionally releasing unfinished software just to gauge market interest. Release-early release-often becomes an entirely new way of doing business.

For seasoned software developers, this change had a varied effect. Some got it right away, some didn’t. More interesting was the effect on corporate cultures. I remember from my time at Microsoft (early Internet era) how the entire corporate culture was built around the concept of bits-in-a-box. This new Internet craze had arrived, but many teams were applying old ways of thinking to the new problems. It’s not too surprising that they don’t fare well on the Internet to this day.

Of course the reverse happens as well. Having started my career building web applications, I remember the tough transition I had when I joined a company doing long-release-cycle software. I hadn’t yet learned the design skills, testing skills, and patience required to truly finish things off before releasing. I kept approaching implementation with a sense of urgency framed by the Internet, and my approach didn’t fit in with the rest of the team.

Any time you begin development on a new platform, one of the first things you need to understand is the release cycle. This is something that has tripped up many iPhone developers. The App Store doesn’t work the same way as releasing software on the Internet. Imagine a curmudgeonly long-time Apple veteran whose been through more OS builds than you have web sites. To him, waiting 4 weeks to get a bug fix out the door is pretty decent. And that perspective undoubtedly influences Apple’s approach to the App Store. Yes, Apple’s perspective on this is wrong, and it will eventually pose a serious problem for them. But for now, it’s sadly the app developer’s problem to solve. Design carefully, test for a long-time, and ramp-down quickly on changes prior to release. It’s not as fun and agile, but it’s doable if you plan for it.

This entry was posted on Friday, November 20th, 2009 at 12:01 pm and is filed under Engineering.