Site icon Schnitger Corporation

How often is too often?

The length of release cycles continues to be a point of contention between developers and users of engineering technology. On the one hand, developers want to get new releases out there to bring in revenue, deal with competitive issues and fix customer bugs. But users are increasingly saying “STOP – we can’t be the guinea pigs for software that’s not production-ready, our IT departments won’t allow upgrades too frequently because it’s too expensive and the cycles are so frequent that we have a hard time adjusting them to our project schedules.” The current trend of 12-month cycles does seem to be falling apart, as many companies refuse to upgrade to a new release until several service packs have come and gone, leading to what appears to be a more natural timeframe of 12 to 18 months.

Of course, this ties directly to how ready the software is for release and many are saying that software quality has taken a big hit recently — in part, to keep up with aggressive release cycles. Several users have said that they resent being beta testers, seeing it as performing unpaid work for a software developer. Back in the day, when I worked at Computervision, being part of a beta program was a big deal. The user got access to new, cool technology before (almost) everyone else as well as a direct pipeline to R&D, which often led to interesting new additions to the next release. Companies wanted to participate and understood that the software wasn’t production-ready. Are vendors today overselling the capabilities of their beta releases? Are they simply not ready for release outside the test lab? Or have the relationships between vendors and users become so fractured that “early look” has come to many to mean “do my work for me?”

Exit mobile version