Optimising Software Management with a DevSecOps Approach

Let’s face it, building software is difficult. It’s mental gymnastics. When your developers are working hard, they’ve likely got at least two hours of ramp up time behind them. Bother them during their meditative state, and you’re resetting that clock, losing hours of potential work.

There’s a flow to programming, and when you’re in the zone, the code comes quite freely. It’s those moments when you’ve been interrupted that do the most damage to a free flowing stream of thought and code.

This is why developers fight against standards and management-enforced tooling. Like a chef demanding their own knives and kitchen equipment, developers can be extremely picky about their instruments. This isn’t necessarily a bad thing, but it can get in the way when management is tasked with improving software quality.

It’s tough to impose development-time restrictions on your teams, as they interrupt that free flow of code to remind the developer of this or that standard. Automatic code correctors and standards imposing tools can get in the way of what your developers are trying to accomplish.

That can be rectified by choosing solutions that get the heck out of the way. If you’ve read anything about Facebook’s development process, you know that they’ve worked incredibly hard to get their build times down to a manageable length. While we all know Facebook as a social media and advertising company, at the core, their true strength lies in optimizing their development platform so that everyone in the organization can play with changing anything they want at any time and see the results in a sandbox.

Facebook has spent, literally, millions of dollars on research to make its systems go faster internally. The company even spent time building HipHop, a PHP to C++ compiler designed to speed the time from development to test click.

Because that’s what you’re really trying to do in your day to day work as a development manager: shrink the time between coding, compiling, testing, and deploying new software.

Trouble is, that period between coding and deploying is crucial for software quality. You already run tests there, you already have your team writing unit tests there, and your build process is likely optimized and standardized in this period of time.

If that time is five days, one week, the goal is to build new software Monday, test it out until Wednesday, and hopefully deploy it Thursday with another day in case things go wrong. In this fantastical world where sprints are one week long, there is only one day of time allowed for intense testing. If you’re not finding problems in that day, or in the deployment phase, they’ll come up in the wild, when your line of business is tied to that software.

Squeezing as much testing as possible into that tiny two-day window, when bugs can be addressed, and while their creation circumstances are still fresh in the minds of the developers, is crucial to succeeding in the goal of continuous integration and continuous deployment.

This is clearly a difficult task, and shouldering the entire burden of testing all possible scenarios for any given piece of software is a full time job in and of itself. Therefore, automation is the key to success, as it is in many development situations.

Perhaps your sprints are two weeks long, or perhaps they’re a month. No matter how long they take, saving days is saving money. Outsourcing some of that test load can only save time and and a result, money.

Better still if that outsourced test load is something that your team is likely not doing already: security testing. For most development teams, security is considered to be the provenance of the networking and operations team, and thus falls under their budget.

The smart development manager, however, can find a place in their budget for security, even if it’s just chalked up to the generic testing funds that used to go to Mercury or HP, but increasingly go to cloud hosted services and AWS-based testing time.

With automated security testing of your binaries, your team can offload some of their day-to-day software quality concerns, and do so without interrupting their minute-to-minute workflow. And with that kind of confidence in your applications, your teams can concentrate on shipping more features, faster.