I’m currently in the midst of speaking to vendors with “commercial off the shelf” (COTS) solutions in order to re-evaluate whether we should be building or buying software to fill a customer need. So I wanted to share some of my thoughts on the evaluation process to hopefully help others.
Purpose for Developers
As software developers, our first reaction is to always build it. It doesn’t matter what “it” is. We just love to write software. Reflecting deeper on this, I think we really want to write “valuable” software with a high return on investment (ROI). In other words, we want to make someone’s day better via code with the smallest amount of effort. If we optimize the ROI, we can deliver more value, faster and this helps give our work a higher purpose knowing that we are helping the maximum number of people.
For example, we could spend months building a fully featured blog engine that ultimately meets all the requirements of our customers. OR, we could setup one of the hundreds of established and capable open source blog engines in days which would is likely to be more feature rich and battle tested. At the end of the day the customers get the same value out of both options but the later they get exponentially faster.
Which feels better to you? You didn’t write the blog engine but the customers will still be amazed that you setup an entire blog for them in a week. And now you can go write software that is new and truly differentiated to bring further value to customers.
Mastery for Developers
Granted, there are will always be secondary benefits to writing custom software like learning something new or learning how to do it better. Mastery is important too and there is a place for it but non-differentiated custom software development while on the customers dime is probably not the best option. If this is what you are looking for, check out Code Katas or try refactoring your differentiated code without breaking the tests.
Here is the list of traits/scenarios I’m using to decide to build vs buy:
Good fit for COTS
- Limited budget
- Lack of technical proficiency
- Lack of time
- Non-differentiated behavior
- Technology not a competitive advantage
- New system where requirements can be constrained by COTS solution
Good fit for Custom
- Differentiated/specialized behaviors
- Technology is the competitive advantage
- Require compatibility/integration with many systems
- Rigid/legacy requirements
- Legacy software replacement
Differentiated Software?
I’ve used this term a couple times already but what does it mean? Differentiated software is code that solves a problem in a substantially new and better way than the alternatives. It typically cannot be retrofitted to an existing solution in a cost effective manner. It is likely the business’s competitive advantage.
We can optimize our costs and time to market by buying non-differentiated software and building differentiated software.
The Iron Triangle
In my mind, this really all comes back to the iron triangle. Custom development fits when your requirements (scope) are rigid and you can’t find a solution to buy. COTS fits when you have limited time and/or budget so the scope is constrained.
It so interesting to go through this exercise to challenge your natural tendencies and think deeply about the best solution for the problem at hand.
What do you think? Have you gone through this process? What did you learn? Please share your feedback in the comments below to continue the conversation.