DEV Community

Cover image for Tales from the Scrum Dungeon: Leprosy As A Service
Joel Bennett
Joel Bennett

Posted on

Tales from the Scrum Dungeon: Leprosy As A Service

Once upon a time, there was a small proof of concept web service that was written, likely in weekend. It was probably written under the influence of alcohol, late on weekend. I don't know all the circumstances surrounding its creation, but at one point, I did have to help support it. It was originally written as a proof of concept. It gathered data from a 3rd party source, performed some basic mathematical operations on it, and returned an output.

It was stood up on a server, shown off as a proof of concept, then promptly forgotten about.

Some time later, it was discovered that the service was still running, and racking up some small hosting costs, so was turned off. Almost immediately, a call came from another part of the company - the part that had been shown it as a proof of concept. It turns out they were using it - in production, and that their production service relied on it. It had to be turned back on immediately.

Not only was it turned back on immediately, but that service was then left running for years afterward. The worst part of it: it didn't make use of standard HTTP status codes. If the app failed with any sort of internal error, it wouldn't return an HTTP 500, it would still return an HTTP 200 (OK), but with a value of -1. It didn't matter what happened to it - it would always return a -1 if it ran into an issue. Pass it a bad parameter? Get back a -1. Server running out of disk space? Return a -1. Unable to legitimately calculate a value because of missing data from the 3rd party? Return a -1. Why was it done this way? The original proof of concept had to integrate with another piece of software. Because the developer of the service didn't have access (or resources) to modify the original software to accept HTTP error codes, it was built to fit the existing software.

The service lasted for several years. No one wanted to touch it, as the code was... unpleasant to work with. It was unpleasant to debug. It was unpleasant to maintain.

Moral of the story? Don't write leprosy as a service. If something is a proof of concept, be 100% clear with that to whoever is seeing it, and make sure that they understand that it is only a proof of concept. Otherwise you might catch leprosy.

Top comments (0)