My product team has a new project for me. It’s ambitious enough I’ve been approved to hire additional staff to support the build out. This is great!
Except, something feels a bit off …
Rather than dive right in with job postings, I stop to ask a senior engineer to double check the math on the project. How many clock hours will it take? How many people will need to work on the project? When will we be ready to ship?
When all’s said and done, the estimate comes in at:
- Two engineers working full-time on the project
- Full-time, in this case, translates to 25 hours per week (50 total) to account for project meetings and break-fix work
- We’ll be ready to ship in three weeks
One hundred and fifty hours. That’s the total cost of the project in terms of “human resources.” It’s also why I felt something off with the request.
The project: automating a weekly report run by another member of the team. His current workflow consumes five minutes of his time once a week. That’s a total of 4 hours, 20 minutes per year.
Spending 150 developer hours to save less than 5. The math doesn’t work. We elected to not invest in this project despite all of the excitement from the product team.
Not invented here
A major issue in the software world today is “not invented here” syndrome. It’s a general bias that, unless we were the ones who built a tool, it must not be any good. This leads to a lot of unnecessarily bespoke software and major expenses in terms of engineering hours to both build and maintain those tools.
My lead-in example was an illustration of how easy it can be to fall down this hole. Depending on a sole engineer to click a button once a week is, in fact, a problem. But spending almost a month of dev time across two different engineers doesn’t make sense from a cost perspective. With the numbers mentioned here, it would take 30 years just to break even on that investment.
The same goes for other software tools.
Yes, it feels great to build your own knowledge base from scratch. But the design and development of that project is not free. MediaWiki, the software upon which Wikipedia is built, is free. It makes more business sense to leverage an existing, free, tool than it does to invest the time required to build a new one.
Free is a relative term
When I speak on free and open source software, I qualify my use of the term “free” as:
- Free as in speech
- Free as in beer
- Free as in a puppy
Often, with free software, we’re dealing with an “as in a puppy” scenario. The code itself is free to use, but you’re still paying for infrastructure to host it and a team to manage it. These costs can sometimes outweigh the value of the free software itself, so tread carefully.
When establishing a new product, the first step should be to find one. If there’s a free, open source application already on the market give it a try. Evaluate how much effort is involved to host and manage the tool. Otherwise you’ve solved your problem for free.
If no adequate free solutions exist, or if the cost of maintaining the tool is prohibitive, then instead buy one. Some of the best open source tools are also hosted in fully-managed, SaaS environments by professionals. It’s also usually cheaper to pay someone a small monthly fee than to staff a maintenance team to keep your own copy of the tool online.
Finally, and this only comes after you’ve exhausted all other options, you should build one. Remember, building a tool means you’re paying not just for the hosting and infrastructure, but also for the dev team to architect and engineer the solution.
Building a tool is the most expensive option. It should be a rare decision in your business unless the tool itself is the product you’re selling to someone else.
