I’m going to start with some jargon, because sometimes there’s just no avoiding it.
My term of the day is “technical debt”. No, this isn’t what overly optimistic people might call their overdraft limit or credit card statement; it’s the phrase we use to describe the inheritance we taken on when we use an “out of the box” solution.
Oops. There’s some more jargon. “Out of the box” is the phrase used to describe a pre-existing product that can be purposed to a variety of applications. Think of a website builder – a piece of software that allows you, and many others, to build a very basic website using a limited number of templates.
Equally, as an agency we might be presented by a new client with a solution they have previously developed, and which they would like us to move over to our servers as part of our new service to them. This isn’t an “out of the box” solution per se, but it’s definitely a case of us taking on a previous developer’s work – and very often we’ll need to fix issues and add new functionality to it.
That’s “technical debt”: taking on and working with the foibles of a previous piece of software rather than building something expressly for a new purpose, from scratch. Few people like debt, and unsurprisingly we’ve found that it’s often better for everyone if we just start again – build new software for the new servers and new systems. That way, we understand the code better, and it’s been written expressly for the current purposes and contexts.
We understand that clients can see things from the other end of the telescope: they’ve paid for a system that does more or less what they want, so why should they pay again for us to re-build it? After all, it will take time for us to write the new version of the application and get it to a stage of maturity similar to that which the previous platform has already reached.
But if there’s no tight deadline, we’ve found that in the long run it will work out cheaper to write the code anew. Why? Because the devil’s in the detail: your time-honoured software only more or less does the job, and that means we’ll be constantly trouble-shooting the gaps between what the software can do and what it needs to do. That bug-fixing costs money, and it will continue for as long as we try to use the old system for new purposes.
Imagine that the old piece of software is a square peg; maybe when it was first fashioned the hole was square, too … but now the corners have shifted slightly and our developers are having to shave a bit off the peg, or fiddle with the diameter of that round hole. If we’d just made the peg from scratch, it would fit perfectly every time – and we’d understand the material the peg was made from better, too, so future improvements would be much quicker and easier for us to implement.
Likewise, if one of our developers builds your software, all our developers can fix it – because we share “frameworks”, another bit of jargon that basically refers to a shared environment in which code is written. Your previous developer’s work will almost certainly use a different framework – and from any security vulnerabilities to its quirks of grammar, we’ll probably be able only to allocate one developer to understanding it. That means that if I spend a month figuring out your old software, and then I’m sick for a week or go on holiday, then James will be totally stuck.
So it might seem counter-intuitive, but starting over from scratch is often quicker and cheaper in the long run. Like any other type of debt, the technical kind has to be paid for again and again – and in that sense I suppose that sometimes jargon isn’t so divorced from everyday language after all.