4

I am more of a high-level wheel reinventor. I definitely prefer to make use of existing API features built into a language and popular third-party frameworks that I know can solve the problem, however when I have a particular problem that I feel capable of solving within a reasonable time I am very reluctant to find someone else's solution.

Here are a few reasons why I reinvent:

  1. It takes time to learn a new API
  2. API restrictions might exist that I don't know about
  3. Avoiding re-work of unfamiliar code

I am conflicted between doing what I know and shifting to a new technique I don't feel comfortable with.

On one hand I feel like following my instincts and getting really good at solving problems, especially ones that I would never challenge myself with if all I did was try to find answers. And on the other hand I feel like I might be missing out on important skills like saving time by finding the right framework and expanding my knowledge by learning how to use a new framework.

I guess my question comes down to this:

My current attitude is to stick to the built-in API and APIs I know well* and to not spend my time searching github for a solution to a problem I know I can solve myself within a reasonable amount of time. Is that a reasonable balance for a successful programmer?

*Obviously I will still look around for new frameworks that save time and solve/simplify difficult problems.

gnat
  • 21,442
  • 29
  • 112
  • 288
Korey Hinton
  • 2,656
  • 3
  • 20
  • 30
  • I think this is too vague to answer well. It's very different to reinvent a `ConvertToDate()` function compare to reinventing a "Download HTML and parse it" library. See [this question](http://programmers.stackexchange.com/q/29513/32347) for some discussion of why it's not neccesarily bad to reinvent, *some of the time*. – Bobson Jun 03 '13 at 18:09
  • 2
    possible duplicate of [Reinventing the Wheel, why should I?](http://programmers.stackexchange.com/questions/55653/reinventing-the-wheel-why-should-i) and of [Is reinventing the wheel really all that bad?](http://programmers.stackexchange.com/questions/29513/is-reinventing-the-wheel-really-all-that-bad) See also: [Does heavy library and code snippet usage make you a bad programmer?](http://programmers.stackexchange.com/questions/34173/does-heavy-library-and-code-snippet-usage-make-you-a-bad-programmer) – gnat Jun 03 '13 at 18:10
  • @gnat I don't think that this is a duplicate since I am asking about the balance between wheel-finding and wheel-reinventing skills. I'm not asking whether it is good or bad in general, I am asking about my own tendency to reinvent. – Korey Hinton Jun 03 '13 at 18:17

2 Answers2

17

External libraries are, in a sense, a form of YAGNI. You aren't going to need them, until and unless you actually do.

Here's why. Every widely-used library out there is designed to satisfy a broad array of programmer needs. It is generalized, in other words. That generalization adds a lot of internal complexity and a learning curve.

Swiss Army Knife

Unless the nature your problem justifies that additional complexity and learning curve, you're better off writing the solution yourself, because you'll get a better fit to your application, less code overall, and in many cases better performance.

Naturally, there are all sorts of exceptions to this rule. If you find a single class out there with a "do whatever you want with it" license that perfectly solves your problem, you'd be foolish to write that yourself. If you need a framework that allows you to write lightweight web applications with excellent control over markup, a clean organizational structure, and a "get out of your way" philosophy, you'd be foolish to re-invent MVC.

To put it trivially, you don't need a 100,000 line math library to solve for 2 + 2. But you might, if you're doing extensive statistical analysis. Nor would you necessarily need a power drill with a Phillips bit if you're just taking the license plate off your car (even though that would probably work). Use the tool that is the best fit for the job.

Community
  • 1
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 2
    Just one remark: Always use a library despite its inherently "more than you need" nature when the functionality it provides has little to do with your application's core functionality but more with the nuts and bolts of making that possible. You will never be able to achieve the same level "completeness" (in functions and in tested-ness) of the library in the time you are prepared to spend on non-core functionality... For example: I have written my own OPFs before. I would now never even consider not using a library or framework for that. – Marjan Venema Jun 04 '13 at 10:40
7

Next time you go for a walk, try counting all the different implementations you see of the wheel concept. The fact that some caveman long ago invented the wheel doesn't people from creating new versions of wheels for various purposes all the time. In the programming world, libraries and frameworks are not like the wheel concept, they're like wheel implementations. In programming lingo, wheel is a design pattern.

So no, of course there's nothing wrong with creating your own tools, libraries, frameworks, whatever. That may be the most expedient approach, and you're sure to get exactly what you want.

On the other hand, you should really get over your reluctance to use things that other people have written. Reusing code is often better than writing your own because you get a tool that has already been written, tested, debugged, and improved, and all you have to do to use it is learn a little bit about its interface. That can save you a lot of time and money. It's not always the right choice, but it's not one that you should automatically reject.

If a set of stock wheels will fit the vehicle you're building, machining a set of custom rims and fabricating your own tires is often overkill. But if stock wheels don't fit, or cost too much, or don't work quite right, building your own may be the best option.

Caleb
  • 38,959
  • 8
  • 94
  • 152