I've always heard that building your own tools is dumb. It's always painted in the light of building on the shoulders of giants. But isn't there a real business case for building everything yourself?
I've always heard that building your own tools is dumb. It's always painted in the light of building on the shoulders of giants. But isn't there a real business case for building everything yourself?
For further actions, you may consider blocking this person and/or reporting abuse
I think the
toolsterm is too general, I'm sure whentheysay it is stupid they have a specific scenario in mind, which is different for each person.Building your internal custom tool to gather marketing data from your DB is not stupid, using random NPM 100LOC packages instead of writing your own, using JS6 or lodash it is.
Everything is a trade off and there's no one guiding principle. The advantage to building it yourself is it's entirely yours and you know how it works and can make any changes you want. It also, ideally, does only what you want it to do and nothing more. The disadvantage is that, well, you have to build and maintain it yourself. If you "buy" (opensource or bought, same story) you are now dependent on that person to maintain their code, do things right, and not do something that breaks your integration in the future.
The classic example of buy-not-build is crypto software. Do you know enough to build that piece securely? Highly unlikely, so a buy option makes a lot of sense here. Using something like Devise that has been vetted and looked at by thousands is more reliable than your home-grown authentication solution.
The classic example of build-not-buy is Node's left_pad fiasco. That is a trivial function you could write yourself and if you had your site wouldn't have crashed when the owner pulled it from the repository.
The harder decisions are things like pagination, tagging, full text search, etc. IMHO in each case you need to examine your business needs and then research the available buy options to look at their reliability, history of maintenance, etc. and then make your decision.
Mike Perham (of Sidekiq fame) wrote an interesting article about this awhile back that is interesting.
mikeperham.com/2016/02/09/kill-you...
1 left-pad
2 flatmap-stream
3 it's coming...
I think it's more related to aversion towards reinventing the wheel. Building software takes time and it's highly unlikely that your tool will be better than something which already exists. In any case, if you're working on hobby project or you're learning, it's quite okay to build your tools. If you do something professionally or you work on the software for which you're sure will reach production, try to stick with tested methods and tools. You'll save lot of time and nerves.
The classic application of the phrase is this kind of scenario.
When I wrote this I was thinking X is "database". Could be filesystem, web server, etc. There is sometimes a dev tendency to see existing tools such as these and think we could do "better". However, the time the team spends building X instead of our product is throwing money on a burn pile. (Unless the product is a database or web server.)
But then some organizations face unique challenges (or have sufficient resources) where building your own is the best play. The example that I heard a while back from Joel Spolsky is that MS Excel team built their own C compiler. And that was a strategic advantage for them.
For an established company, the question is whether the investment will eventually turn into revenue. For a startup, it's also a question of whether the company can keep the doors open long enough to see it.