Tag Archives: technology

Positive Technical Debt part 3: Investor demanding payout

This is a slightly different problem related to Technical Debt and one that is more difficult to manage.

In financial terms I would liken this to having an initial investor who gives the business capital with no expectation of repayment. This capital drives expansion, but a certain point the investor demands full repayment.

From a technical perspective this is when a technology selection is made because it offers benefits in terms of business progression that allow you to get to where you need to be in the most beneficial way (e.g. because of speed of development, easy availability of staff, availability of other technologies/partners to integrate with). The system can be developed in a correct manner with no technical debt but at a point when technology becomes unviable and the only way forward is a fundamental re-architecture of the system.

The sort of events that could lead to this are

  • You reach the limits of the technology in terms of capacity for the level of usage that you now have. An example of this would be Twitter and Rails or Facebook and PHP. On a smaller scale I have worked with companies who wrote their first system using Access as a database and as the company grew hit the capacity of that platform and had to re-architect to use another database.
  • The platform/technology used is no longer available. This is a scenario that has become more likely now that people are using more 3rd party cloud based services. It is possible to wake up one morning and discover that a core part of your system is actually no longer available.

Again this is a positive form of technical debt, as it is taken on board with a view to getting benefit from a system as quickly as possible.

The way to deal with this sort of technical debt is largely down to good system architecture. Systems should be architected in such a way as to abstract away the connection with technologies as much as possible, making swapping them out as simple a job as possible. Systems should be built to horizontally scale to allow capacity problems to be dealt with by throwing tin at the problem. It can also largely be dealt with by technology selection; the majority of systems we write have a predictable growth plan (not many of us write Twitter!) and we can make a reasonable estimate of the longevity of technologies and technology providers.

Other posts in this series:


Leave a comment

Filed under Code, Technical Debt