In our software environment, we often run a/b tests, as is probably good practice. However, our environment is set up such that, in very short order, the code starts to become very crufty with dead tests. The testing registry is little more than a collection of internal wiki pages.

I thought of a "dead man's switch" style of defunct code management. If you're not familiar with the term, it refers to a switch that must be reset periodically in order to keep something from triggering -- in essence, if you don't responde, the switch triggers, and whatever you wanted the switch to trigger is performed.

For example, I would write some code, register it with this system in some way, and when a date of my predetermined choosing rolled around, I would get a notification that this code would be removed (automatically cleaned up) unless I intervened (manually clean up, or snooze).

What are the pros, cons and viability of incorporating such a system? Is it possible or wise? What might be some alternative ways to manage code against rotting?


I'd be worried about a system that automatically removes code. Unless your team is very well diciplined, I can only see this as a road to tears and pain. Things happen: people go on vacation, get sick, leave the company, forget what the code that's about to expire does, ... and having code be automatically cleaned up sounds like it will invite all kinds of trouble. You'd have to ensure that there are no compiler dependencies between these modules, or they could suddenly fail to compile when something they depend on gets expired out of existence. And don't forget what would happen if someone in production support is working on a older trouble ticket and the stack trace in the error message references code that was deleted. And this would not make people who do auditing very happen either, I imagine...

Something that might be safer is a framework where your little modules of code can query for an activation date and a deactivation date. When the piece of code is about to run, it checks in a database for what is dates are and if the current date is between the activation and deactivation date, your framework allows the code to run. And if you store these dates in a database, you could easily write a script that will generate a report of all modules expiring in the next n days, and email it to you so it's the first thing in your inbox on Monday morning.

  • This could be great if integrated with a ticketing system. Thanks! – dclowd9901 Jan 28 '13 at 16:43
  • 2
    activation/deactivation can be expressed with a licensing system of which there are many available, so you wouldn't even have to write one yourself. Individual assemblies can have such licensing systems applied to them such that accessing any of the exported interaces of said assemblies would automatically verify you have an available license (that hadn't expired) with a floating license server. – Jimmy Hoffa Jan 28 '13 at 17:35

This system creates a problem of orphaned tests: if someone who wrote a suite of tests and a set of production code associated with it departs the company, the tests are in danger of being removed prematurely by omission of their new owner.

I do not think that "too many tests" is a problem: as long as tests are automated, your waste is limited mostly to CPU hours, which is small change compared to man hours. A test removed automatically through the dead man's switch could catch bugs that would otherwise end up in production, causing severe maintenance problems down the road.

I think you can build a process-based alternative by creating a registry pairing up test suites with modules of your code. Every time a maintenance is performed on a module, the process would require making a decision on keeping/removing/updating the corresponding test suite. Since this is a pure bookkeeping, there is no danger of code being removed from the list automatically.

  • 1
    I figured the orphaned code issue would be very relevant, but was hoping I was just dumb enough to not know of an automation alternative. But I'm glad you presented another alternative, even if it isn't automated (which we can both agree would almost certainly end up in tears). – dclowd9901 Jan 28 '13 at 16:43
  • @dclowd9901 - Why are you not removing tests that tests the code your removing? Furthermore shouldn't the tests be contained within the same file its testing or the very least, a comment within the code which tests are ran? – Ramhound Jan 28 '13 at 18:55
  • Laziness? In all honesty, I came into this system long past its initial implementation. The tests themselves rope off code under certain circumstances. They literally sit alongside the code themselves. – dclowd9901 Jan 29 '13 at 0:08

I have long used simple calendar alerts (whatever calendar software your company uses should suffice) where I simply set it to alert me at whatever time and I put all the information I'll need presume I forgot everything by the time the alert goes off.

Install an ssl cert? Look at the expiration date, set a calendar event for myself (and a manager and another engineer in case one or 2 of the 3 of us happen to no longer be with the company, which has happened) 2 months before that to start sounding the alarm to whomever that it need be replaced, put in the event the contact information for the people we received the cert from, the specific places the cert is used and details of systemic ramifications of letting it expire (maybe it's a dead system and the cert should expire when that time comes around).

Automatic code modification is a downright terrible, dangerous idea. All you need to do is judiciously use your calendar to make sure you are notified of time sensitive things when their time becomes relevant. This is specifically what calendars are for. Now if you have a problem of not heeding time sensitive events in a responsible manner, I think you have an altogether different problem that you might want to ask on the workplace about.


Sounds like a very bad idea, because later code will depend on those changes. Automatic rollback will cause widespread damage.

Instead, write your tests as automated (unit) tests, and run them nightly.

  • Automated unit tests? How would that work with interaction tests? – dclowd9901 Jan 28 '13 at 16:44
  • @dclowd9901 - If thats the case just ran them as often as all the other interaction tests are ran. It shouldn't be hard to figure out which interaction need to be ran not ran at any given point. If its difficult then your process is the problem. – Ramhound Jan 28 '13 at 18:57
  • @dclowd9901: I hope you're not actually changing the UI on a weekly basis, even if the code behind the UI changes that frequently. Users don't like UI changes, just ask Microsoft. So what you would be testing is that the UI remains sufficiently identical. – MSalters Jan 29 '13 at 8:03
  • In webapps, we have opportunities to test different UI approaches (be they tweaks in placement or color, or whatever) in a very rapid iteratable fashion, so we take advantage of that. However, weekly changes they aren't. Generally data is collected over months. – dclowd9901 Jan 29 '13 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.