Those of you who know me know that I am opinionated about maximising return on investment and maximising the speed of delivery. The more I’ve discussed concepts around software delivery the more I see delivery teams as a system. So I’ve decided to put together a series of Blog posts to explore this further, I’d love to hear the opinions of other to help me develop my thinking on this.

If we can think of the delivery team as a system we can start thinking about the organisational architecture as though we were designing a software system. One of the things we try to do in the software development world is ensure that the way different parts of a system interact with each other is optimised for performance (all aspects of performance not just speed). Let us take a server for example, we wouldn’t want CPU utilization sitting at 98%, we wouldn’t want memory utilization sitting at 98%. That’s just asking for trouble.

To maximise the performance of a software system, one of the things we do is to try where possible to make as processes asynchronous. But that has some inherent implications with regard to state, we end up trying to make as much stateless as possible, event sourcing is a great model for something like this.

However, lets take this back to a software delivery team, how much state can we manage in software delivery, and how do we communicate. We’ve ended up being so reliant on email, some people even treat it like synchronous communication expecting an immediate response. But email isn’t synchronous communication between 2 people (or more depending on how many are in the address box!), getting a response requires someone at the other end to drop what they are currently doing, open the email, read it, investigate/action the request and then respond, i.e. given that we are reliant on the recipient to pick up the message when they are avaiable, communication via email is inherently asynchronous. And how about instant messaging tools, yes, these are better, but we can think of these as HTTP connections, if we were to receive 100 different messages from 100 different people simultaneously we wouldn’t be able to respond to all of them. If it was me, I’d probably close down Skype at that point. In an application, we’d probably put in place throttling to make sure that the service doesn’t degrade for everyone if we start getting too many connections.

The key problem we have is that unfortunately, unlike a software system where you can put in place caching and some sort of event sourcing, there is only so much state we can manage when we are doing our work. Our work is stateful, our work is stateful and the way we make decisions is stateful. If we had to work on something which completely depends on state, we probably wouldn’t try to make it asynchronous. If the way we work is stateful, maybe we should try to make sure that we work in a synchronous manner, requiring that we get immediate responses from the things that we are dependant on.

Taking this a step further, having a true product owner sitting with the developers means that the development team can get an immediate response to questions they may have on what they are working on, putting in place unit  tests as part of the solution means that the developers get an immediate response when they are running their tests, merging code changes locally means that we get an immediate response when we are developing as part of a team.

Maybe we should only have synchronous steps in the the software delivery lifecycle so that we don’t have to try to remember what we did 3 months ago. This in essence means developers need to test, QA isn’t a separate department and neither are the release engineers or production support. Maybe asynchronous development is an anti-pattern.