Uncharted Waters

Aug 30 2017   3:19PM GMT

The Illusion of Speed in Software

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Slack space

Most of the process I have experienced in my last several years while working at software companies was designed to create the illusion of speed to market, but very little actual speed. The development teams get a sprint backlog of entirely too many changes, work their way through them by spending too many hours in the office, and them move all the cards over to ‘test’ in JIRA. Testers get a few days, get through as much as they can and then the release date comes calling.

The teams I see going faster, have slowed down.

Those releases almost always went out on time with the right feature set. Or at least as much of the right feature set as the development team could muster up. To get there though, everyone had to make sacrifices. Not just in terms of skipping code quality activities like unit testing, running tests through CI, and code reviews, but also in testing activities after the product was mostly whole.


The results of this was bug reports coming back from production. That is a manageable thing, and happens to anyone that is building software, but this was not a trickle. Each release had a couple of new problems that had to get crammed into the next sprint. This created a cascade affect for the development team. The first release was all features, the second was release plus bugs, the next was release plus bugs plus a couple of hotfixes. The team slowly gets bogged down in junk that doesn’t result in new software for customers.

The teams I see that escape this cycle are moving slower and dealing less in vanity metrics like velocity, the number of bugs fixed, and the number of features pushed to production.

There is an entire set of tooling — CI, build and deploy pipelines, testing APIs, and containerization — that a lot of people are using in addition to radical collaboration (extreme programming). But we don’t even have to go there. Jamming less changes into each release is the simplest and easiest place to start. It requires no process changes, no new tooling or architecture.

Delivering a few less changes each sprint gives people room to breath. Instead of the cascading cycle of releases compounding with more emergency maintenance work, each release looks something like this. Developers take new features one at a time. They work on them for a little bit, build some unit tests, get code reviewed after or in real time, and then extend an invitation to a tester or product person. The developer and product person do  some testing in the dev environment, find a few bugs, and things get fixed before a real build happens. Once the change makes it to a test server, most of the low hanging fruit generally found by the testing group has been resolved and they can spend time on more important things.

This change doesn’t need facilitation or process review boards, it just happens because people have more time to do a good job. Building in slack time is the reason development groups get things like build/ deploy pipelines, containers, and layered testing architecture.

Speed is an illusion in software development. Groups I have worked with that move fast aren’t really delivering much. The groups I see moving slow end up with more new software at the end of the year. Build some slack, build some better software, make your development team happy.

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Matt Heusser
    "Build some slack"

    Can't we just use skype? I think slack is over-hyped. And building your own INTERNAL slack system, that's just crazy.

    I kid, of course.

    Building your own internal collaboration tool is a GREAT idea. It worked for us at socialtext. :-)
    4,780 pointsBadges:
  • clankmaster
    The crazy thing is... what led to this requirement for such fast paced development and deployment?? Normally you might say, well of course, it was the consumers... But is it really?? Look at MS with it's SQL Server releases... 2012, 2014, 2016 followed by 2017 on it's heels!! This tends to be very confusing for most customers as they do not know which way to turn. In another year there will likely be SQL 2018 or 19 available... We no sooner get upgraded to one version and just start to get comfortable with it and another version comes out! This creates a lot of consumer/customer confusion... Should we upgrade again or just stay put. I am not sure who Microsoft determined really wants or needs this fast paced development/production schedule (I know tons of development companies are doing this, not just MS) but it does not make good sense to me. I don't think anyone really wants it. It was likely created by some high level brass who really had no idea what type of issues they were about to create. Let's just burn people out... I think that's what they were thinking, because really, we are burning out the analysts, DBAs, developers, testers etc... etc... everyone involved... What does that mean?? It means many of our good people move on so they can have their life back... It means we have to spend countless hours in the hiring and training departments again, which now potentially stresses our HR departments as well! Overall, this entire crazy development process that appears to be the norm with so many software development companies is straining everyone involved, customers as well (as per this article with poor software going to market) and for no real good reason at all! Customers aren't demanding it and don't really care! They just want to be comfortable on a solid version of whatever software they are running for a little while and not have to worry about deciding whether they need to be upgrading right away due to a newer version being released. They just want their existing software to work!! So, whoever started this, please STOP IT!!!
    20 pointsBadges:
  • neosysinfo
    Development speed is in part a reality and a need, but on the other hand that stressfull, under/or/overpaid many many times. When we think in terms of effort and man-hours required to fix 'ilussional', uneeded or simply overstated features, we can't beat good old common sense, team happininess and a good schedule with proper and toughtful requirements.
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: