Stop Your Project's Zombification Now!

Too many software projects die early. Even worse, many of these dead projects end up in zombie like state, slowly shuffling forward. The won’t fully die, but they certainly aren’t alive.

These projects are a drain on your time and money.

How does this happen?

Usually its due to mismanagement of the project from a technical point of view. How do you avoid zombification? Three suggestions:

1. Use boring technology
2. Keep your code “DRY”
3. Create seams between third party code

Boring Technology

Boring technology means using standard old technology with a proven track record. These choices are typically reliable, well understood, and less expensive. There is almost certainly a bigger company using the same tool, which means the big, hard, and weird problems have already been solved by someone else.

With new tech, you might be the biggest user, which means you need to solve all those big, hairy problems yourself.

The underlying technology is not likely the unique value proposition of your business. You should let someone else focus on that so you can focus on your core.

Keep Your Code “DRY”

Don’t Repeat Yourself, DRY, is a coding mantra that says you shouldn’t repeat different concepts in your code. Copy and paste is the enemy of DRY!

By having every concept in your code only once, it means you can update the code in one place and it will be used throughout the system.

In contrast, I joined an existing project where every screen that involved payment processing had its own, slightly different, copy of the invoicing code. This meant every change would need to be replicated and adjusted in a dozen places.

This greatly increased the cost of every change until all these disparate pieces could be extracted into a single shared piece. This is DRY in action.

Create a Seam Between Third Parties

When connecting with code from third parties it is easiest to just use it directly throughout your code. One of the big downside of this approach is that if you every need to change what third party tool you are using, you need to update everywhere that it touches your code.

A much better solution is to create a seam.

A seam is a small, isolated chunk of your own code that sits between your system and the third party. When done right, nothing in the system will ever use the third party code.

This means if you ever want to change the third party tool, all the changes will happen in the code for the seam.

Two examples of where I’ve used this:

1. Replacing a mapping provider with Google Maps since Google was cheaper in this situation.
2. Switching from a singe text messaging provider to multiple competitors simultaneously. This let us reduce costs and increase deliverability.

Because a seam was in place, both of these large changes resulted in no changes to system code.

Having this kind of flexibility with your third parties gives you options and control over what tools you use, while minimizing the costs.

Avoiding these three classic errors helps ensure your software isn’t a member of the walking dead.