Listening to a recent Ruby Rogues podcast the topic of Technical Debt came up that really rang true for many of our projects and clients.
The discussion notes that the point of Agile is to get a product to market as quickly as possible to prove the business value or otherwise of an idea. In the course of an Agile project decisions are made to facilitate this. It might be a quick and dirty feature, not having full test coverage or hacking together a quick library to support a feature going into production.
The point is that this is completely correct - you want to get a product out there and prove a business idea. But there should be a realisation that if you are developing and supporting software long term there will be a point at which these decisions will have to be paid back.
In almost all of our projects at pebble we have examples of this and this represents normal, Agile software development. But discussing Technical Debt with a client is a good way to let the client know in simple, understandable terminology of the impact of a decision. By discussing it this way we can be clear that at some point the debt from a decision may have to be repaid. By the same token there will be scenarios where taking on more technical debt is the right choice.
In the context of our work depending on how much debt a project / client wants to take on there is a good case for us scheduling a debt repayment sprint in our Agile projects once and a while. The business value is that it will support future features, stability and decrease long term development costs. There will also be cases where accruing debt is completely acceptable. It should be assessed on a case by case basis.
I like this terminology in terms of how we can work through business level decisions with clients and make informed choices for the direction of Agile software development.
We have been prone to sharp intakes of breath at feature requests in the past and have explicitly stated this is something we hate noticing ourselves doing. As an Agile house we should never being saying no to features but positioning them within a business context and helping clients to make informed decisions. Terminology like Technical Debt lets us do that and communicate clearly and openly with the client.
The discussion comes highly recommended if you are involved with Agile software development.
Have an update or suggestion for this article? You can edit it here and send me a pull request.
Rolling deployments with Kubernetes
How to deploy a new version of an image into a Kubernetes cluster
Getting started with Kubernetes
How to get started with using Kubernetes on a local machine using minikube
Listening to BBC Radio with mpv
The BBC publishes high quality 320 kbps HLS AAC streams that can be used to listen to radio from the command-line using mpv. Here are the URLs and some aliases to start listening quickly.