This is part of a series to help entrepreneurs and business owners make the best use of their development budget. See more entries here.

Uncompilable code

One of the most expensive, and common, mistakes entrepreneurs make is keeping their codebase in a state where a new developer can’t come on board and make changes quickly. This is most often because the code doesn’t compile. If you don’t write software you probably aren’t thinking about this. Don’t take it as a failure, most developers don’t think about this either. But the business owner is the person who has to write the check for the next dev to come in and get the code in a compilable state before they can start working. This is an expense that provides zero value for your company.

How does this waste money?

Uncompilable source code is as valuable as a broken car. It may be worth something, but you have to pay someone to fix it before it will take you anywhere.  You want to spend your budget on new features but instead you’re forced to spent it on something that provides no value. On top of that, it’s draining for the new developer. It’s a myth that consultants just want billable hours. I do this because I like to solve problem and help people grow their business. Getting an uncompilable system into a compilable state is one of the most tedious tasks a developer can do. It’s like a extended game of whack-a-mole. You fix one error to reveal 10 new ones. Nobody wins. The developer hates it and it’s money you spent that doesn’t improve your bottom line.

But my app is in the App Store, of course it compiles…

Just because your previous developer could compile it, doesn’t mean anyone else can. As a developer myself, I know it’s easy to get a codebase into a state where it only builds on one machine. This is most common where a single developer has been working on the project for a while. A team of developers can often weed out this problem naturally. But even if you have a team it makes sense to make sure your application can be built at anytime.

Here are some common causes for this:

Missing 3rd party libraries

The project might rely on a 3rd party library that only exists on the previous developers machine. In many cases this isn’t a difficult fix – the new dev can download the library themselves and start working. But sometimes it isn’t obvious which version of the library is needed. I once inherited a codebase where the required library version wasn’t a standard release I could easily download, it was a beta release that had been customized by the previous developer. This would have been a very expensive job to get this code working. Luckily, we were able to get in touch with the previous developer. If they had taken off backpacking in Thailand, the project would have been in serious trouble.

Hard coded project paths

Related to the 3rd party library problem is project files referencing paths that only exist on the previous developers machine. These hard coded paths can mask the fact that essential libraries aren’t included in the project file system.

Required components on the build machine

Some projects require 3rd party components to be installed on the development machine to build. This is usually to protect unlicensed use of a purchased library or SDK (Software Developer Kit). This is less common, but something to watch out for.

But I only work with the best consultants

As I mentioned above, these things are easily overlooked. I’ve inherited code from some of the best in the business that didn’t compile.

Not only startups

It is not only startups that face these problems. I once worked with a company that spent millions acquiring a product they couldn’t build. They had a released version, but the components required to build were so complex it could only be built on a single laptop – a laptop that was close to falling apart. Guess who got spent weeks re-implementing that mess? This was a 5-6 figure mistake.

Another case is another company that spend millions purchasing a startup. When the original founders had left, the purchasing company realized they couldn’t build the software. They needed to hire a consulting firm at top rates to get the mess figured before they could start adding new features. This is something that should have found during due diligence, and definitely a cost that could have been avoided.

What can I do?

While this is an easy mistake to make, avoiding it isn’t hard at all.

  • Make compilable code part of your deliverable. Make sure someone in your organization can build it. If you don’t have someone technical in house, that person it YOU.
  • All 3rd party libraries should be in the project directory and checked into source control.
  • If there are special instructions or components to install, make sure the steps are documented. Have the dev walk you through and document the steps if necessary. It’s much cheaper to have them document this now, than pay someone else to figure it out later

Tired of working with developers that waste your money? Talk to us, we can help you build something amazing.

Join the conversation!

  • …Or keep a virtual machine with a clean dev environment that you can use to verify a fresh checkout builds cleanly.