A co-worker once said to me, "I can't wait until this project is finished."

We had been working on a new web-based application for almost a year already, and we were nearing our first release. That made me think: it really shouldn't be finished, otherwise it's as good as dead.

To be clear, I'm not saying to never deploy the software. Also, this isn't about a 'Pied Piper' scenario where we had engineered something that, unleashed unto the world, would basically turn into Skynet in a few years time.

This application we were working on was a responsive Angular SPA replacement for the dated .NET version that had been in production for years. The software needed to be updated because it wasn't serving our business needs anymore. Since it was using such outdated technology from top to bottom, the best path forward was to scrap it and rewrite the entire thing.

So the software was effectively a zombie. Living in production, but simultaneously dead. This happens a lot - a team assembles and develops software. They become experts in the intricacies of the business and users' needs as well as the details of the implementation. Finally, the project is deployed to production and everything works great... for a time.

Inevitably the users' needs change or the business needs evolve. The team that had originally created the software has moved on to other projects or maybe they've left the company. In short, no one is really familiar with the specifics of the implementation; maybe it lives on a box that isn't maintained like the newer ones. Or likely it uses frameworks, libraries, languages that are rather old.

The best case scenario you can hope for is that members of the old team are there. However, I'm sure you know how fun it is to effectively dig up the past or relearn code that you wrote years ago. There are always surprises.

We have another piece of software that, after 3 years in production, the users would like some updates. A lot of the updates are minor fixes/presentational; making things more consistent and fixing typos. There are also some feature requests like adding new columns to the data grids in the application.

Seems innocent enough at first glance.

This software is another example of the living dead. It's using very outdated versions of packages (some betas and others alphas) and to update it would likely be just as much work as rewriting it. There are a host of security vulnerabilities, janky code, as well as an inconsistent user experience. It would also absolutely be a lot of confusion and frustration to 'git clone' and get to work.

We've determined a rewrite is the way forward, but the pain doesn't stop there. The current development team is trying to get access to the system in production so we can effectively create our new wireframes and user stories. It's always much easier to use an existing piece of software to understand it as opposed to reading a functional requirement document.

This is turning into a black hole - there's an email chain with 29 messages (and 30-something recipients) going back and forth just to give us access to the current system. We've had a number of meetings already too and keep dragging new people into the conversation. And we still don't have access yet. It seems no one knows exactly what combination of permissions one needs. So, there are more emails to come...

Just think about all the time spent on just these emails and meetings. Of course, not everyone is actively taking part in them, but they are yet more work/noise for everyone involved. And worse still, they are one more blow, however slight, to the confidence in our development team. No one knows why we can't get access - we're relying on people's memory when the project was first done to figure it out. And this is just the beginning.

Ideally though, the solution for this is to NEVER FINISH IT. Continuously update, patch, rewrite, and develop your software. Maintain it and modernize it and don't leave it for dead.

We're going to migrate this application onto our platform that's in constant development. It's the only way to avoid another complete rewrite down the road. Sure it'll be more effort to maintain, but that's the cost of software.

So next time you think about the relief you'll feel when a project finally 'finishes' just remember this post. Your entire team will be better off never finishing that application.