Jez Humble had a fantastic piece on the Continuous Delivery Blog about a recent Voke report on Agile.
I encourage you to read the assessment and analysis so I don't have to re-write it here... instead I want to focus on something I'd been going on about since I started this blog - software quality.
This phenomenon must be something that is ingrained back in the human mind somewhere that's just not possible to root out... or else it's something else unexplained.
Of course I'm referring to the notion that slow somehow equals safe. You can hear it in the high school driver's education instructor's voice, and see it on Sunday mornings as people who only drive once a week get out onto the roads doing 45mph in a 55mph zone because they must somehow feel it's safer.
Forget about the fact that they're in the left lane and cars behind them are losing their minds, and making dangerous passes just to get by - but I digress. You get the idea.
I remember entering the IT workforce learning that slow and deliberate is the way to not screw something up. If I was upgrading a system I was to take my time, "measure twice, cut once" (remember?), and always not rush. Then as IT became the bottleneck for the enterprise, speed started becoming the thing.
New systems faster, set up users faster, scan faster, patch faster and yes... deliver applications faster. It's not surprising that methods like Agile and DevOps came to life. Waterfall is just so rigid, so... slow and inflexible. But you know what they say - slow and steady wins the race right? I don't know...
Now we're reading Jez's post and the Voke report and they're really not too high on Agile. It seems like there's the perception that agile somehow means a departure from a focus on quality. You should care because security is a function of quality. We've been agreeing on this for a while now, so let's take that as a given... or is it? Apparently not.
I admit, I've meandered over to the dark side. I had a hard time believing that "going faster" could be more secure. It was difficult to wrap my brain around how deploying code in more rapid succession could mean that the code deployed could actually be safer... but I believe that to be true now. The one caveat here is "if it's done right".
The point here is that poor security practice - you know, when you're trying to force developers to read that 100 page PDF you wrote from the last penetration test against a production application - is unsafe at any speed of delivery.
If you're relying on "a scan before it goes live" to keep your applications at an acceptable level of security you're screwed whether you're delivering through Agile, or Waterfall ...or if you're doing one release a year.
Two key things that will never change: 1) you can not force security into a software development lifecycle, and 2) poor security practices are unsafe at any delivery speed. Now, what you're going to do about this varies by where you work, how you develop, and who is responsible for security.
I'm concerned that enterprises are still not getting the message that Agile is just a valid delivery mechanism as anything else out there, especially when it's in the writing of a respected analyst firm... but this is the real world. You should be able to read that and know it's crap for yourself... numbers can be 'interpreted' in many ways, and opinions are like belly buttons.
Anyway, speed isn't the issue. Speed should never be the issue. If you're blaming the speed of your software organization's delivery on the lack of security - you're doing other things wrong, and the result is probably your fault.
Cross-posted from Following the White Rabbit