The software time bomb

I have wrestled with the ethics of time bombs and I have come to the conclusion that like so many controversial business practices, it’s all a matter of context. So what exactly is a time bomb? Well, it is a programmatic procedure that, when a certain landmark is reached (usually a date), disables or cripples the software in some way. Sounds nasty eh?

In reality, you have probably used many programs that had time bombs in them, but because of the way they were presented, they really didn’t seem all that dramatic. Most people have heard of the term “Shareware”. Most shareware will have a time bomb with accompanying “nag screens” informing the user that they have 30 days to register before certain functionality is reduced or disabled altogether. But what about in the context of a bespoke application? Well for a start, I simply don’t think a developer can pronounce at the outset of a project that he will be using a time bomb to protect the investment of his time – that would put a big dent in the relationship from the outset. I did once use a time bomb when dealing with a new startup business: The cost of the project was £1,000, the client did not want to pay the full amount up front and I did not wish to take a risk on a completely unknown quantity, but I still wanted to reassure the potential client and get the business. The solution? We agreed that the client would pay £500 up front and that the software would cease to function if the balance was not paid 30 days after the client had signed off the software as fit for purpose. This solution worked well because we both felt that we had adequate and fair protection of our investments.