Software devs' new mantra: Zen dogs dream of small-sized bones

'BIG' is for old-skool bosses


One of the primary principles of DevOps is moving from large software releases to a series of small batches.

What do we mean by “large”? Six-to-12-month (or longer) projects that follow the infamous “water-scrum-fall” model. While development teams may create builds weekly, the code isn’t deployed to production and used by actual users each iteration.

“Large” has strong appeal. It optimises the planning, development, and deployment phases of software. Planning teams want time to gather all the requirements and detail them out in exquisite documents, making The Boss feel like they’ll get exactly what they want.

Developers and QA nowadays tend to like working in an iterative manner, chunking their work into one- to two-week increments. However, operations feels that the highest chance of failure comes when you deploy, so why not minimise deployments? Each group creates the process that makes them feel like they’re doing their job well.

Despite the warm and fuzzy feeling you get from a well planned, staged out process, taking a small batch approach is showing more success. As one IT manager at a large organisation puts it: “We did an analysis of hundreds of projects over a multi-year period. The ones that delivered in less than a quarter succeeded about 80 per cent of the time, while the ones that lasted more than a year failed at about the same rate.”

If that’s “large”, what do I mean by “small”? Here, it’s reducing that entire cycle down from six to 12 months to a week - or even a day. And yes, you back there with your hand up: this means deploying a lot less code each time, hopefully just a handful of changes, or even just one.

Focusing on smaller batches is mostly about reducing key areas of software risk. Those risks being:

  1. Bug swarms: If I have a week’s worth of code vs half a year’s worth of code, and something goes wrong in production, there’s a much smaller set of code to diagnose and fix. This also speeds up your ability to deploy security patches.
  2. Useless software: The biggest risk in software is creating software that users don’t find valuable but that’s otherwise perfect. With small batches, because you deploy each iteration to users, you can easily figure out if they find the software useful. And even when you get it wrong you’ve only “lost” a week (though, I’d argue you’ve “won” in gaining valuable learnings about what does not work).
  3. Stymied innovation: Coming up with new ideas can take a very long time if you have to wait six months to try out new ideas and see how your users react. Instead, if you deploy a series of small batches, you can experiment and explore each week, hopefully getting into a virtuous cycle of steadily discovering new ways to delight users.
  4. Budget overruns: A small batch mentality avoids “big-bang bets” that require a massive capital outlay at first and then a white-knuckling 12-24 months of waiting before shipping the code. If you’re only focused on the next few releases, finance can adjust funding either up or down as needed. The existence of government IT projects going over budget serve as an example here (though, I assure you, private industry can be just as bad: they’re just better at hiding failure).
  5. Schedule elongation: Projects that don’t force shipping can often find themselves forever stuck with just “a few more weeks” left before shipping. There’s always new features to add, more hardening to do, and then it’s the holidays all the sudden, and you’ve got a good month of downtime, which is just long enough to think of still more new features to add. Without an emphasis on shipping every week you eventually slow down.

Small batches let you improve the quality and usefulness of your software by creating an ongoing feature experimentation process. Small batches mean greater control over the budgetary and planning aspects because you can spot problems early on and act accordingly, theoretically – at least – after each weekly release.

Overall, The Business feels like it has more opportunity to manage, conferring upon those in charge a sense of empowerment and control. No more nasty shocks from IT.

But, and here’s the problem: small tends to cause a loud clunking noise in the minds of The Business and of The Boss. These folks are not always comfortable moving beyond that big stack of promises. “What, Henderson? You want me to do small?! At Waddleforce &co, we’re all about BIG!”

How do we in IT circumvent this and sell the merits of “small”? I suggest discussing small batches in terms of risk management and the “optionality” that the approach creates, something that business-heads usually understand and value.

As IT proves out the small batches approach, then the code crowd might have something to teach the suits. ®

Similar topics


Other stories you might like

  • Want to buy your own piece of the Pi? No 'urgency' says Upton of the listing rumours

    A British success story... what happens next?

    Industry talk is continuing to circulate regarding a possible listing for the UK makers of the diminutive Raspberry Pi computer.

    Over the weekend, UK newspaper The Telegraph reported that a spring listing could be in the offing, with a valuation of more than £370m slapped onto the computer maker.

    Pi boss, Eben Upton, described the article as "interesting" in an email to The Register today, before repeating that "we're always looking at ways to fund the future growth of the business, but the $45m we raised in September has taken some of the urgency out of that."

    Continue reading
  • JetBrains embraces remote development with new IDE for multiple programming languages

    Security, collaboration, flexible working: Fleet does it all, says project lead

    JetBrains has introduced remote development for its range of IDEs as well as previewing a new IDE called Fleet, which will form the basis for fresh tools covering all major programming languages.

    JetBrains has a core IDE used for the IntelliJ IDEA Java tool as well other IDEs such as Android Studio, the official programming environment for Google Android, PyCharm for Python, Rider for C#, and so on. The IDEs run on the Java virtual machine (JVM) and are coded using Java and Kotlin, the latter being primarily a JVM language but with options for compiling to JavaScript or native code.

    Fleet is "both an IDE and a lightweight code editor," said the company in its product announcement, suggesting perhaps that it is feeling some pressure from the success of Microsoft's Visual Studio Code, which is an extensible code editor. Initial language support is for Java, Kotlin, Go, Python, Rust, and JavaScript, though other languages such as C# will follow. Again like VS Code, Fleet can run on a local machine or on a remote server. The new IDE uses technology developed for IntelliJ such as its code-processing engine for features such as code completion and refactoring.

    Continue reading
  • Nextcloud and cloud chums fire off competition complaint to the EU over Microsoft bundling OneDrive with Windows

    No, it isn't the limited levels of storage that have irked European businesses

    EU software and cloud businesses have joined Nextcloud in filing a complaint with the European Commission regarding Microsoft's alleged anti-competitive behaviour over the bundling of its OS with online services.

    The issue is OneDrive and Microsoft's habit of packaging it (and other services such as Teams) with Windows software.

    Nextcloud sells on-premises collaboration platforms that it claims combine "the convenience and ease of use of consumer-grade solutions like Dropbox and Google Drive with the security, privacy and control business needs." Microsoft's cloud storage system, OneDrive, is conspicuous by its absence.

    Continue reading

Biting the hand that feeds IT © 1998–2021