Building and running a successful company requires an immense amount of work and talent. It also requires focus. Companies cannot try and solve problems with new and innovative techniques everywhere they operate. It is important to understand the areas your company should innovate in, and outside of that scope, use existing standards and off-the-shelf software as much as possible. There is only so much innovation that a company (or the market) is willing to bear and walking that line is a key factor in developing a successful product on time and budget.

If your core product is e-commerce, maybe you don’t need to develop an innovating logging system? Yet, I often overhear conversations among engineers that are derisive about paying for software that could help them focus on their core competencies, thinking it would be cheaper and easier to just do it themselves. “I could build that in a weekend”, is said with such conviction that it is hard not to believe it is true. The fallacy here is that engineers consistently underestimate how long projects will take, consistently undervalue their own time, and typically fail to consider maintenance and long-term support as a cost of building software. In reality, paying for software is often the cheapest, easiest, and most straightforward solution to the problems that we can’t afford to be innovative with.

One reason why we choose to build instead of buy is that building is the lowest barrier to entry. It doesn’t require a product comparison, or a business analysis. Even more important, it means you don’t have to talk to a sales engineer, or justify the purchase with a presentation to an executive. By building instead of buying, you can just sit down and work on something you like, rather than doing a bunch of tasks you really don’t. Unfortunately, “low barrier to entry” doesn’t mean “easy”. In fact, it’s quite frequently the opposite. We may be able to get a basic prototype ready in a weekend, but this is extremely misleading. We all know that the last 20% of a project can take up to 80% of the time and effort, and we know that software maintenance can account for over 75% of the total cost of a project. Yet we conveniently forget this when we have the opportunity to work on a nice, new project.

Software engineers easily fall into the trap of believing that writing code is the primary responsibility of their job, often forgetting that solving business and customer problems is what you are paid to do. Sometimes the best way to solve a problem is with code, but sometimes it isn’t. Being able to recognize the difference between the two is a key factor in growing as an engineer. Engineers that can solve business and customer problems without writing code are to be celebrated, which is why I argue that vendor management should be a core competency of senior engineers. Successfully managing a vendor integration should be taught, developed, and rewarded as much or more than we celebrate writing code and developing software engineering skills. Code is a liability, and we should reward engineers who avoid it.