Managing software work effectively is one of the biggest factors in improving efficiency and performance. When a developer picks up a task on a project they don’t usually work on, there’s a real cost – not just in time, but in focus. Context switch for a developer comes at a substantial cost. They prefer to focus in one space at a time, because their work is extremely focus oriented. Software is really complex. A lot more complex than the marketing and surprisingly low cost of consumer software would lead most people to believe. If you take software like Excel it’s had billions spent on its development, but you can rent it as part of a package for about the price of a Netflix subscription.
However, when you commission custom software development the cost can be a shock both during development as well as afterwards during support and maintenance. Although this article is largely about support, it’s also covering a real problem that happens in development when a developer is expected to switch between different sections of a project to deal with found bugs or new change requests.
One way to reduce costs is to gather work, support and changes up together into blocks of related work and to appreciate that not everything can or should be fixed immediately. You only do that for items that are real business blockers.
We always suggest the following categories of urgency:
⬜️ Low – nice to have, plan for later
🟦 Normal – routine maintenance or small improvements
🟨 High – needs attention soon to prevent impact
🟥 Urgent – blocking issues requiring immediate attention
We try to tackle work in order, with urgent coming first, inside a scheduled plan. This keeps projects predictable and reduces firefighting.
Why? Here’s the picture:
When an issue comes in, there’s a lot more happening than just “fixing a bug”. Developers must load the project, recall how it works, set up the environment, test changes, communicate and then shut everything down again. All of this takes time.
In one analysis (see figure below) the setup and shutdown time alone to about 6510 second, compared to 3600 seconds of actual coding and debugging. That’s nearly an hour of overhead for every hour of developer time.
But if we batch related work together, the efficiency improves dramatically:
The above illustration shows that we have 3300 seconds of setup and shutdown with 10230 seconds spent on the work. Comms time is reduced also.
Of course, all this depends on a customer prioritising well – if every task is an urgent task, and we don’t have enough time to complete all the tasks then we won’t stop to check the clock – we’ll assume it’s a blocking problem and that the cost of the fix is always going to be lower than the cost of not fixing it. It is, as defined by the customer, urgent. And that calls for focus. Which may result in uncomfortable overage bills and difficult account management conversations.
Hopefully the above is a useful guide as to why we like to structure support in the way we do. It doesn’t mean we don’t want to be fixing things super quickly. We’re just trying to watch your budget.
Featured image by Andreas Klassen on Unsplash
