Back to Posts

Build vs Buy in Software Engineering

There has long been a debate of "build vs buy" when it comes to a software solution. You can either build the thing yourself which allows for complete control and customization or you can go out and buy the thing (or find an open source alternative) which allows for a speedy implementation. There is no "right" answer, but there are certainly some things to consider with each.

I started my engineering career in the "build" camp. I wanted to build everything myself. I had SO many projects when I got started. I was reinventing the wheel every week - mainly to prove I could do it to myself or to learn a new skill. I think if you are starting your software engineering career, this can be an incredible asset to building your repertoire of skills. As time goes on though, it can become detrimental.

When you start coding, there aren't many projects. Building them all is fine when there are a dozen or less; however, you'll realize shortly after that you suddenly have dozens of projects that now need maintenance, documentation, test suites, etc... keeping up with all of that can be incredibly taxing. You now realize you've sunk hundreds of dev hours into something just to find an open source alternative that is more feature rich that's been around for years and does the same thing - I've done this myself over and over. As the years have gone by, I've started to take a shift in my approach to engineering - electing now to start more in the "buy" camp (or the open source world). Slowly, past projects have been archived and abandoned in favor of using something that has been on the market for awhile with strong community support because it "just works" and saves me countless hours of development. Of course, going this route, you give up the control you would have by building a solution yourself and so the selection process becomes more important. Things must be well documented, fully tested, feature-rich, and have a strong community backing its future development.

My new approach is to always search out an off-the-shelf solution first and only build when there is no alternative that fits your needs. You'll find when you spend less time building and more time grabbing off-the-shelf solutions that fit your needs - you'll have a lot more time to then go back and build a custom solution to a problem that has yet to be solved - and that is ultimately the definition of a "Software Engineer".


Justin Hammond
I love all things tech. I've been programming since the age of 12, repairing iPhones since 16, and founding tech companies since 20. I'm an open source fanatic, Apple fanboy, and love to explore new tech. I spend my time coding open source projects, tinkering with electronics and new tech products, and consulting teams on how to get things done.


Comments

Please login to leave a comment.