Don’t roll your own if you don’t have to

Repeat after me: It’s okay to use third party libraries and frameworks. Okay. Now say that three more times.

I’m not saying you should just grab something from GitHub randomly. What I’m saying is that there are a lot of mature third-party libraries and frameworks that are worth using. The initial investment of finding them and figuring out how to use them, can save you a lot of time down the road.

Examples we’re using for jodiBooks are Bootstrap, Castle Windsor, AutoMapper, Entity Framework, React Native. Edit: now that Joep has taken up coding, I can’t leave out our jQuery and Redux of course πŸ˜€

Many software engineers prefer, however, to “roll their own“, for various reasons. I’ve seen hours and hours spent on typing thousands of lines of code, where a library or framework could have done a lot of heavy lifting for you. Look up from your desk and ask the question “Hasn’t anyone already solved this problem for me?”

β€œAll truly wise thoughts have been thought already thousands of times; but to make them truly ours, we must think them over again honestly, until they take root in our personal experience.”


As human beings, we have to be willing to acknowledge that the chance that our problem (or its solution) is unique, is exceptionally tiny. There are stories of the pre-internet era – when the world had a tenth of the current population – of researchers, engineers and mathematicians independently coming up with the same ideas. Our thoughts aren’t unique. Of course, the people who make remarkable breakthroughs are without a doubt creative and inventive. And of course, your problem could be a question nobody has asked before and yes, you could be the first person working on it. It’s how a lot of frameworks actually came into existence. But for now, I’m going to assume you’re writing code to get a thing done for your company. You wouldn’t be doing it if you didn’t know it could be done. The company wouldn’t have sold it to the customer, otherwise. So, you probably have a deadline to meet.

The most important conclusion for anyone working at a company that is not doing pure research: Many people have probably done similar work. Your job is to figure out how best to do it in your specific situation, and you are bound by time.

Why do some engineers still write a lot of code by hand when you could use a third-party library to do it for you? Why are we developing yet another ORM framework, why are we writing yet another logging library?

A. The project needs something new

Category A: You’re developing something from scratch, because the goal itself is to do so. You’re searching for a new way of doing something.

Early adopters and pioneers work on libraries or frameworks that don’t exist yet. Or, if it exists, is experimental and/or feature-incomplete. All mature libraries started out this way. Some or all of the following may apply:

  • You’re an early adopter
  • The platform you’re working on is not mature yet
  • You’re developing in your free time / It’s a personal project
  • You’re building something from scratch to learn from it
  • There’s no pressing deadline

B. Your project requires strawberries

Category B: You’re developing something new because you have an additional requirement that none of the existing libraries/frameworks seem to satisfy. Vanilla doesn’t cut it.

You found some libraries and frameworks. You tried them. They work for the most part, but there is some downside that is somehow specific to your situation. You don’t get any traction. You decide to roll your own. The project has to go on, after all.

Please be aware: You may, some time later, stumble upon “To do X, combine with Y and Z”.

If you find yourself in a situation where a framework or library almost does what you want, “except for this one scenario X”, consider asking for help. Post messages online, reach out to colleagues. If need be, call in an expert. Don’t assume that just because you can’t find it, it’s not there. Sure, you may spend a day searching. You may spend a day’s worth of consultancy fees. Or you could blindly start coding for weeks and roll your own, not knowing that another, shorter and easier, path had been available.

If you find that you really have a unique use-case on your hands, then you may end up writing a lot yourself. But it doesn’t necessarily mean you can’t use any third-party software. A car with three wheels still needs a steering wheel, pedals, chairs, and windows…

C. Not invented here

Category C: The company has adopted the Not-Invented-Here stance. Only code that is developed in-house is accepted.

Some companies have a policy of never using third-party code. Or they have a legal department where you have to jump through hoops to use third-party code even if it has an MIT or Apache license. In other cases, someone who has a big say the matter refuses to even consider using third-party software.

I’ve encountered the mindset several times. In mature organizations you’ll probably hear mentions of the magical creature called “presenting a business case”. If only you could calculate for them exactly how much time (read: money) it would save, they might be willing to consider letting go of NIH. I’ve heard “presenting a business case” mentioned many times. I haven’t encountered one in the wild yet. If you want a sure fire way to discourage your employees from telling you how to save time and money, send them away with the words “If you could only present us a business case…”.

In this scenario, you’ll often be confronted with intangible things that we humans like to pretend are real and important. Things like ‘time’, ‘money’ and ‘legal implications’. But, what matters is not how much time you spend, how much money you earn or whether you own the rights to every single thing you do. What matters is that you are adding value for your customers. But that’s a topic for another time.

When you’re faced with ‘time’, ‘money’ or ‘legal implications’ as arguments, most of the time it means “We don’t want to think about it.”. It’s not until you have had a frank discussion with someone higher up who lets you know they’d truly be interested in pursuing this avenue and who will have your back, that it would be worth your time to try to convince them.

D. Weird perspective taking

Once you get past the first three reasons to not use a third-party framework or library, you enter the land of weird responses. Things like “The quality will be higher if we write it ourselves”. Quite a bold statement. Or, my personal favourite, when talking about frameworks that have been around for years: “These new technologies haven’t proven themselves yet.”

Ahem. Excuse me. What programming language are you working in?

Okay, great.


Why aren’t you still coding in assembly?

Yes. Seriously. Why would you ever have left assembly? Why would you ever switch to an OO, or functional programming language? Go To Statements have worked in the past, haven’t they? Why would you ever do something new? Oh, you need to host a website? Well, what’s stopping you from developing your own web server in assembly? Oh, you want a database and CMS as well? Well, that shouldn’t take too long to build from scratch. Right? Yes, sure, you could use all this new-fangled stuff, but why would you ever do that?

Oh, you’d rather use C# than assembly, you say..? Uh-huh. Because you’re more productive in C# than in assembly, you say? Okay, that’s fair. But on the other hand, you’d prefer writing your SQL migration scripts by hand and create your database deployment scripts manually rather than let EntityFramework Code-First do the heavy lifting for you? Dear gods, why?

If I have seen further it is by standing on the shoulders of Giants.

Isaac Newton

If you were building a house, would you buy a tiny oven and bake every brick by hand? No, you wouldn’t. (Please say you wouldn’t…) Someone else has already solved that problem and they can deliver you a near endless supply of bricks much faster and more reliably than could achieve with your tiny on-site oven. And yet, some engineers even go as far as to start building an oven. Please. Stop.

I am fairly sure that the most reliable code I’ve seen and used so far, is code written and maintained by a community. Four eyes see more than two. Thousands of eyes… you get the point.

The promised land of “Once we’ve written it ourselves it’ll be better” is a fairy tale. That third-party software you’re talking about? It’s real. It’s there already. It exists. It’s usable. Thousands of people have used it before you and have already squashed a gazillion of bugs. It’s stable and it’s documented. You can visit their support forums and ask questions. Your only price of admission is reading the docs.

0 Replies to “Don’t roll your own if you don’t have to”