If You Build It, They Will Complain

It’s been said that some of the best programmers in the world are incredibly lazy. And when you think about it, this makes a lot of sense.

Programmers tend to be obsessed with efficiency. Whether it’s writing as few lines of code as possible, memorizing every possible keyboard shortcut, or creating scripts that automate repetitive tasks – developers thrive on efficiency.

Larry Wall, creator of the Perl programming language, best describes this unique trait: “Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.”

But in listing his Three Virtues of a Great Programmer, Wall also notes that great programmers also possess a great deal of hubris. He claims that hubris is what drives developers to create innovative solutions that they can take pride in. But for large organizations, this hubris can lead to conflicting tensions between IT and other functional teams when it comes to making build vs. buy decisions. 

You see, when the need arises for an internal software solution, it’s not uncommon for IT to insist on building the software internally rather than purchase a SaaS solution from an outside vendor. And even though IT has the best intentions when offering to spearhead these complex internal projects, building an internal solution comes with a variety of unexpected consequences.

As someone who has been around developers for most of my professional life, it wasn’t long before I became obsessed with programming and efficiency. Ever since building my first VBA script in 2012, I began looking at the world through a new lens.

From that point forward, every mundane task became a new and exciting challenge. Instead of taking time-consuming work at face value, I’d evaluate the pros and cons of building a simple solution that could help automate the repetitive workflows that would otherwise eat up hours of valuable time.

To give you an example, my first project was aimed at automating our company’s executive dashboard. Every week I was asked to download several reports from our central reporting system, manually update the metrics in our Excel dashboard, and then provide commentary to summarize the key observations. Once I realized that this process came down to predictable copy-and-paste and some simple logic, it was just a matter of automating each manual step.

After two weeks of gruelling trial and error, I had successfully written my first automation script. By turning this weekly process into a button-click operation, I was freeing up more than 10 hours of work each month. 

Needless to say, I was excited by the potential of this new-found skill set.

Build, Support, Rebuild, Repeat

Before long I had colleagues knocking at my door to craft nifty solutions that could help them carve out hours of tedious work from their schedule. Whether it was data entry, report building, or simple web scraping – I had a knack for building small scale automation projects that saved our team hours each week. But little did I know that my hobby was about to turn into a part-time job.

Just like the IT departments at large companies, I had created a scenario where I was building internal tools that I wasn’t prepared to support and service. The excitement clouded my foresight – and I didn’t consider that each new project would require regular maintenance and ongoing support. I would get asked to add functionality or work on bug fixes, which amounted to several hours of additional work each week. Worse yet, I was on the hook when something stopped working at the worst possible moment.

The Dirty Truth and Tips For Success

It’s easy to underestimate the true costs of building an internal solution. IT teams tend to be overly optimistic about timelines and the ongoing costs associated with building a solution in-house. A 2011 study on small to medium-sized enterprises found that in-house development projects tend to take longer to implement than externally sourced solutions, and also require a higher level of managerial commitment and effort.

In-house projects are also prone to mismanagement and poor planning, resulting in projects that fail to deliver on the expected benefits. In McKinsey & Company’s 2012 report entitled Delivering large-scale IT projects on time, on budget, and on value, the report describes one example of a large bank that wanted to create a central data warehouse to overcome inconsistencies in their data. In this particular example, the end goal was never properly defined and the IT department embarked on building a solution that never considered the actual business objectives, resulting in ‘huge amounts of unnecessary complexity’ and significant cost overruns. After 18 months of missed deadlines, nearly $10 million in sunk costs, and no working solution, the bank decided to stop the bleeding and cancel the project altogether.

On the bright side, these types of situations can be avoided through proper due diligence. To avoid surprises, there are three important questions that every decision maker must consider when making the decision to build an in-house solution:

1. How long will this really take? Sometimes IT teams can be overly optimistic about timelines. Considering that it can take a SaaS company several years just to build an MVP, it’s important that you ground your team with realistic timelines. Be sure to ask your IT department for the full development timeline up front, and schedule milestone dates and regular check-ins to avoid surprises.

2. Who will be providing ongoing support? What your team needs today will be different than what your team needs in 6 months. Eventually your requirements will change, or something will break, and you need to be sure that you won’t be left high and dry when it matters most. Ensure that your IT team provides guarantees for ‘post sales’ support, and don’t forget to build these ongoing costs into your budget considerations.

3. What am I sacrificing?It’s not realistic to expect that your IT team can build a solution that fully competes with that of an external vendor. After all, SaaS companies tend to coordinate all of their resources to build a single solution – whereas your IT team must split time between your project and all of their other deliverables. It’s important to consider what you’ll be sacrificing, and how this will impact the output of your team.

Prioritize Your Needs

When you begin to boil it down, there are a variety of hidden risks to consider when deciding to build an in-house solution. Whether it’s time delays, feature limitations, or minimal ‘after-sales’ support – there are many land mines that you must be aware of before going down the path of a DIY solution.

So when making this complex decision, be sure to carefully assess your risks and opportunities, compare the fixed and variable costs accordingly, and choose the solution that allows your company to grow without compromise.