Code released before it’s ready might be good for meeting deadlines, but that’s about all it’s good for. Most software products today are in a continual state of development, testing and release, so making sure you’re only shipping code that’s truly ready is both challenging and critical.
Our 2016 Global Developer Survey asked respondents about how they work, what they work with and what makes their jobs easier (or harder!). They told us resoundingly that between deadline pressure and unrealistic expectations from management, they end up releasing broken or non-functional code all too often.
Over half of developers admit to releasing code before it’s ready
The frequency of shipping incomplete code varies, but an overwhelming 81 percent of developers admitted to releasing code before it’s ready, with an alarming 15.75 percent saying it happens more than half of the time.
This isn’t the same as releasing early and often, although the two are easily confused. It’s common practice to release features that are not necessarily polished, with the aim of gathering feedback and improving with the next iteration. However, releasing code that isn’t ready refers to code that is incomplete, not yet fully functional, or hasn’t been tested across all environments. The pitfalls here are obvious: shipping code that’s not finished can break things and result in frustrated customers.
Why does this happen?
It seems obvious that releasing too early should be avoided, yet it happens all too often. Why? Pressure from senior management and deadlines that must be hit were the top two answers from our respondents, with 38.34 and 58.9 percent each, suggesting a breakdown in communication and mismanaged expectations between senior management and development teams.
How to prevent premature releases
Having a robust release management strategy is essential for planning and controlling your software delivery schedule. Leveraging Continuous Integration and Continuous Delivery to ensure your code is always tested and ready to be deployed at a moment’s notice helps to prevent the release of broken code. Adopting DevOps practices to improve communication and collaboration between teams and encourage shared responsibility for each release is another way to ensure that deadlines are realistic and can be met.
Also, it might sound counterintuitive, but releasing more often can actually help to prevent premature releases: if you’re shipping once a month instead of twice a year, there’s no reason to rush code that isn’t ready into your upcoming release just to meet a deadline.
Download our Global Developer Report to learn more about what developers want and need to do their jobs more efficiently.
