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.
Using HashiCorp Vault with LDAP
How to use HashiCorp Vault to setup an LDAP backed secret store with read-only access for users in groups and read-write access for specific users
Linux and Unix xargs command tutorial with examples
Tutorial on using xargs, a UNIX and Linux command for building and executing command lines from standard input. Examples of cutting by character, byte position, cutting based on delimiter and how to modify the output delimiter.
Copy a file in Go
How to copy a file in Go. The ioutil package does not offer a shorthand way of copying a file. Instead the os package should be used.