I recently had the privilege of attending the Redgate hosted SQL in the City Summit in London. It was a great event and the highlight of my day was to talk to Steve Jones and Grant Fritchey.

However, something bothered me on one of the topics which Steve presented. He talked about developer productivity and how DevOps makes developers faster. The slideshow can be downloaded from Redgate at https://assets.red-gate.com/events/sitc-summits-2019/london/building-quality-into-continuous-delivery.pdf. I highly recommend that you have a look at what was presented, It was a fantastic set of presentations that changed my Boss's thinking on how we approach our assessment of developer productivity.

The slides don't make too much sense without context, but Steve's very valid point was that traditionally we have a trade-off triangle: speed of development, cost of development, and quality of product. Traditionally you can pick 2 out of 3. We can, however, get all 3 if we adopt great practices.

A few years ago the company I worked for employed an Agile mentoring company in order that we understood how the process worked. One of the exercises involved developers sitting in a line and trying to get their product over the line as fast as possible. Behind each developer was a project manager with a stopwatch, we timed each individual and also the total time to get the pennies to market.

This involved having the first developer having a pile of pennies all "face up",  he has to turn them over one at a time and then pass them to the next developer, each developer turning over pennies and passing them to the next person only after all the pennies are flipped. This occurs over and over again until the final person pushes the product across the line. This represents a development style where the developers can't start until the business analyst has finished, the test team can't start until the dev team has finished and so on.

We were shown a different methods of doing this penny game, which gave us a new idea of how to build software where the team was faster and the product got to live much faster. The new method proved to be quite illuminating. The first developer turned over one coin and passed it, therefore allowing the next developer to flip it and passing it on. we then kept going until all coins hit the finish line.

In the first exercise the individual Development time was quicker, but in exercise 2 we found an unusual pattern. The individual developers took much longer to complete their own tasks, but the time to get all of the pennies over the line was reduced by a huge 60%.

So, this is what bothers me. A lot of developers feel pressured to perform, and they work long hours and shortcut good practices. This makes everything even worse downstream when support people have to pick up bugs in live code. In reality these make the team slower, like the 1st pennies exercise.

Sometimes going slower makes the team faster. This is where Devops, good source control, regression testing, performance testing is overlooked by a developer under pressure. But while avoiding doing those things makes an individual faster, the team is much slower.

We're still working on this, We're putting in object level recovery and row level recovery tools from Redgate, while it's making us slower we will be faster in the long run. We're putting DevOps processes in place that slow us down, but stop us from making mistakes. In short, Devops and you make the "team" faster and the product more scalable.

I’m not knocking Steve’s presentation, which indicated that  "devops makes developers faster", but I prefer the message that “Devops makes the product get out faster, even if  you don't feel as fast as an individual."