Sometimes reinventing the wheel can be a good thing. Jeff Atwood wrote an article that ends with this conclusion:
So, no, you shouldn’t reinvent the wheel. Unless you plan on learning more about wheels, that is.
You have to be very selective about which wheels you’re going to reinvent. Trying to do everything yourself from scratch is the road to poverty. But in your area of specialization, reinventing a few wheels is a good idea.
Buy, don’t build?
Years ago I subscribed to the “buy, don’t build” philosophy of software development. Pay $100 for a CD rather than spend weeks writing your own buggy knock-off of a commercial product, etc. (This isn’t limited to commercial software. Substitute “download an open source product” for “pay $100 for a CD” and the principle is still the same. Call it “download, don’t build” if you like.) I still believe “buy, don’t build” is basically good advice, though I’d make more exceptions now than I would have then.
When you buy a dozen incompatible components that each solve part of your problem, you now have two new problems: managing the components and writing code to glue the components together.
Managing components includes sorting out licenses and keeping track of versions. Commercial components may require purchasing support. Using open source components may require monitoring blogs and list servers to keep track of bug fixes and upgrades.
Writing the glue code is a bigger problem. Mike Taylor calls this “the library lie.” This is the idea that your problem becomes trivial once you find a set of libraries that together do what you need to do. But integrating all these libraries may be more work than writing more of the code yourself.
I’ve run across this problem especially with ORMs. Your gains in development time are quickly eaten up with rewriting code you find needs to go beyond the capabilities of the ORM. Then you find that your ORM doesn’t do certain tasks efficiently, but you lose days figuring out what they are and rewriting the code that uses them. Finally, you have only a few places left that use the ORM, and you decide that removing the dependency is worth the time to rewrite those modules. You’ve now spent about one and three-quarters the time it would have taken to write the data-access code in the first place. (Not that I’m bitter.)
I generally think “buy don’t build” is a good idea.
Who wants to write their own XML parser, scene graph manager, ORB, GUI Toolkit, much less all of those? You’ll never get your own value added out of the door if you reinvent all of the wheels.
But, yes, the glue code can be onerous as well.
This is the reasons frameworks like Qt and .NET exist. They generally provide many of these common things that you’d like to use, but do so in a conceptually coherent way. Plus vendors of other tools often provide hooks into these various frameworks. For reference I am a Qt fan.
Not that frameworks are a panacea either. Adopting a framework is a major decision and you can not divorce yourself from one easily.
I work with mathematical and statistical software and I think the build vs buy argument leans strongly towards “buy” for all but the simplest algorithms. The time/cost of prototyping and writing an algorithm is only one cost. There are additional costs of creating unit tests, “real world” tests (i.e. are the algorithm’s API and results conducive to using it as one part of a larger analysis) and documentation, as well as the ongoing costs of maintenance (e.g. verifying consistent results across different operating systems, hardware, and compilers). But I agree very much with the notion that you often learn something best when you have to tinker and go through the exploration joy/pain yourself. Whether you go on to actually use the wheel you reinvented as opposed to the existing one is another matter.
Josh: The “buy” argument may be stronger for numerical software than for other kinds of software. Mathematical functions suggest their software interfaces and so you might not need too much glue code to combine offerings from two vendors.
It takes a lot of maturity to say “That was educational. I’m glad I did it. But I’ll use a better version someone else created.”
Well guys – as a geeky person I prefer the “first build-then see that your own algorithm sucks-then buy anywhere but has a much deeper understanding of the problem, solution and domain than before” approach.
Of course it’s somewhat suboptimal (timewise) but as someone without real private life I do the first part (partially) in my “free”(sic)-time.
I just could not stand to be just a better lego-brick-consuming-mindless-programming-zombie – I do this stuff because I like the ocassional “think about it” – kick.
In any other way I might be wasting my time – you can make (much) more money with stupid monkey-behavior by joining the financial sector ;)