Why is it so hard to decide to buy?

A tweet that generated a lot of feelings

Optimism and Fun

  1. We want to believe ourselves to be special, and our situation to be unique. We over-focus on the edge cases that are not perfectly solved by off-the-shelf tools, and ignore the complexity of providing the main features in addition to our desired edge cases. We believe ourselves to be better engineers and capable of solving the problem in a more-perfect way.
  2. Building is fun, and the work of integrating an existing product often sounds tedious. As an industry we’re still struggling to move from telling engineers “your job is building brand new things from scratch”, and our whole style of teaching computer science is first-principles based, which encourages the default to build ourselves. The industry has not thought much about what makes someone good at integrations, or what the opportunities are for engineers who are doing integration work to learn new things and feel challenged and stimulated.
  3. We underestimate the work of building, and the total cost of ownership of having our own special product. It’s easy to see the bill for your SaaS software every month, and hard to appreciate that the engineering cost to build an internal version is still probably higher because you haven’t factored in the opportunity cost of having engineers build that system instead of contributing to more core business opportunities. Perhaps you think that you can lessen this bill by making the project open source, and having community support for the effort. In reality, even if you somehow manage to build a community around it (an extremely challenging thing to do), now you have to balance moving the project forward in the way your company needs and moving the project forward in the way the community might need. Building OSS might still be the right call, but it’s not a free option.
  4. Companies reward people who create new things. It is hard to identify and reward problems that are avoided. When it comes time to evaluate people, we look at systems built from scratch and believe their authors show more technical talent than those who completed similarly-challenging integration projects with less raw code. Most companies promote those who create new systems even of questionable value much faster than they promote those who might be making wiser choices by not building from scratch, which creates a pressure to build in order to grow your career.

Making the decision to build or buy

When integrations bite back

Problem 1: Buying a bigger solution than you need, and then feeling obligated to use all of it.

Problem 2: Evaluating every option out there for every decision.

Problem 3: Over-vetting every product.

Problem 4: Underestimating the work of integration.

Problem 5: Neglecting to speak to the value of what the engineers are providing when they aren’t building from scratch.

Wrapping Up




Author, “The Manager’s Path.” http://amzn.to/2FvjeHH Distributed systems, dysfunctional programming. camilletalk.com, elidedbranches.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

DevOps Handbook Series Part 3: Practice Continuous Integration

I don’t necessarily know that it’s fair, honestly.

How To Create An Advanced Website Crawler With JMeter

Solr upgrade from version 6.X -> 8.X + a Road from Master-Slave to Solr Cloud … Fuss-free!

Dynamic PDF with Markdown and JSON (Laravel)

Dependency Inversion Principle: The magic trick that will change your class without changing it

#Elixir — where is the state kept?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Camille Fournier

Camille Fournier

Author, “The Manager’s Path.” http://amzn.to/2FvjeHH Distributed systems, dysfunctional programming. camilletalk.com, elidedbranches.com

More from Medium

Engineering Principles (v1) at Nextdoor

Structural Lessons in Engineering Management

Three myths about high-performing teams

What is Engineering Enablement

Engineering Enablement