Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

One thing working in Haskell and F# has taught me is that someone in a university smarter than me has probably already found an abstraction for what I'm doing. Likewise in C# and object-oriented programming, there's probably a library for "it", whatever it is that I'm doing.

There's such an emphasis on reusing abstractions in programming that I often feel a dilemma between: 1) just coding something short and dirty myself or 2) spending the same time to find someone else's more robust library/solution and just using that.

Like recently one of the coders here wrote up a (de)serializer for CSV files, and I couldn't help but think that something like that is probably very easy to find online, if it doesn't already come with the .NET standard APIs.

I don't blame him though, several times working in .NET I've patched together a solution based on what I know, only to realize that there was some method call or object or something ,often in the same library, that did what I wanted and I just didn't know about it.

Is this just a sign of inexperience, or is there always an element of trade-off between writing new and reusing old? What I hate the most is when I run across a solution that I already knew about and forgot. I feel like one person just isn't capable of digesting the sheer quantities of code that comes prepackaged with most languages these days.

share|improve this question
add comment

4 Answers

First, you need to learn to identify "components" that are generic/reusable enough that a library or 3rd party solution is likely to already exist. Once you do that, realize that, even if you are a good developer, the collective experience of countless developers spending countless hours on the same problem is likely to have produced a solution better than you'll ever be able to do. That doesn't mean you should never "reinvent the wheel", but if you choose to do so, you better have a DAMN good justification for doing so.

There's such an emphasis on reusing abstractions in programming that I often feel a dilemma between: 1) just coding something short and dirty myself or 2) spending the same time to find someone else's more robust library/solution and just using that.

It's worth mentioning that even if it takes you the same amount of time to find an existing library/solution as it does to write it yourself, remember that doing it yourself also means you'll have to maintain it forever. You're not just re-inventing the wheel, but also the entire pit crew to keep it running. Of course, some libraries are buggy or poorly maintained, but these are things you should keep in mind when picking a 3rd party solution.

share|improve this answer
2  
Oftentimes though, you might end up spending more maintenance time on a library even if it's good and actively maintained. Usually this happens when it was designed in such a way that just so happens to not fit in with your code somehow. –  Jason Baker Nov 1 '10 at 21:35
    
+1 for justifying the time spent on searching for existing library/solution. –  rwong Dec 24 '10 at 8:58
    
+1 for pointing out the pit crew, we always seem to forget about them –  Filip Dupanović Jan 18 '11 at 18:17
add comment

Welcome to the world of programming. This issue will be the subject of many disagreements between you and your future colleagues. You have two options:

  1. Roll your own.
  2. Build something on top of someone else's solution.

I think there are times where both solutions are appropriate. For instance, I would prefer to avoid rolling my own CSV parser of ORM if I can avoid it mostly because it's pretty tedious work. On the other hand, libraries are often restricted. I would say that for every project I've worked on, I've encountered libraries that would solve my problem perfectly if not for this one shortcoming. Or sometimes a library is exactly what you need when you first start out doing something, but is more harm than help once you need to make changes.

In general though, I'd advise against trying to find "correct" answers because they don't exist. When in doubt, just go with your gut. I once heard someone say that experience is defined by how many stupid mistakes you make. So usually, you'll either learn something or make something that works. Either way, it isn't all bad.

share|improve this answer
    
I'd say it's a three-way choice: roll your own solution for this particular need, adapt someone else's existing solution, or roll your own general-purpose solution to handle this need as well as future needs. The fact that it's a three-way choice makes it much harder than a two-way choice would be. –  supercat Nov 18 '12 at 15:58
add comment

Sometimes this is a sign of inexperience, whether with the particular language or with programming in general. Sometimes, though, if the fit isn't obvious it's just better to roll your own code that does exactly what you want and nothing more. Generic libraries, while often useful, can be built for requirements that you simply don't have, and in some cases this level of genericity can make them more trouble than they're worth.

Example: For my small one-man projects, I never use a "real" logging library. I use print statements plus a little ad-hoc configuration. I don't want to be bothered with setting up and configuring a logging library that has way more features than I'll ever use, when print statements works fine for my purposes. I also don't want yet another dependency that might not be compatible with the version of the compiler/interpreter I want to use, would have to be distributed, etc.

share|improve this answer
1  
...or the other way around. Sometimes it was tuned for a very particular task and just isn't flexible enough to do what your code needs it to do. –  Jason Baker Nov 1 '10 at 21:45
    
This is what I was going to answer –  DominicMcDonnell Nov 2 '10 at 2:28
add comment

This (or a similar thing) has often happened to me in a previous job where the framework was suffering from severe Inner Platform Effect.

Basically, their code base evolved from early days Windows C/C++, then started to be compiled under MFC - and so the maintainers started mixing MFC and their old in-house data structures and windowing components. The inner platform wasn't very well documented, but it was supposedly "The Way" to do things on that product, due to some internal facilities that it provided. I often found it easier and quicker to write my own stuff from scratch (from MFC fundamentals), rather than work out how to do it with the company's internal framework.

(Okay, so this seems to be almost the opposite of your initial point - but the principle is the same, hehe! Yeah, sometimes it really is quicker to do your own thing than to spend time and effort to find an existing re-usable solution.)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.