Jonathan Rentzsch continues an interesting thread started by Andrew Leonard’s interview with Scott Rosenberg in Salon about programmers’ apparent need to continually reinvent the wheel by rewriting code that other people have already written. They both have interesting takes on it. Rosenberg says:
Programmers are programmers because they like to code — given a choice between learning someone else’s code and just sitting down and writing their own, they will always do the latter.
And Rentzsch continues:
Rosenberg is wrong. Programmers don’t like coding, they like problem solving.
If programmers liked to code, we’d all be writing in machine language to this day. You can write that stuff all day and get precious little of the real problem solved.
They both have good points, but I think this really needs to be put in the context of a real software development project to be understood.
One thing I’ve started seeing a lot in the past couple years is business owners looking at a problem, doing a Google search on "the problem + open source", finding at least three or four different projects that seem like they fit the bill, and deciding that programming from scratch isn’t necessary. Sometimes they’re right–it depends on what you’re trying to achieve, and how closely your target matches with the target of that project. Often though, they’re wrong, and the project gets shoehorned into an existing framework that doesn’t really fit the business need.
Regardless, though, this results in the programmer having a predetermined solution thrust upon him by the business owner:
Business Owner: "Here, this open source package handles CRM. We just need CRM plus order entry and fulfillment, so just build order entry and fulfillment on top of this."
Developer: "But this wasn’t written to handle order entry and fulfillment."
Business Owner: "Here, here’s the source code. You can just use that. You put down three months for the CRM portion of the project on the project plan, and we need this software yesterday, so if you use this we can shave three months off the project."
Developer: "But this wasn’t written to handle order entry and fulfillment."
And if the shoe doesn’t fit, they’re SOL. From this point, the project can go one of three ways:
- The open source package is actually customizable and module enough where plug and play integration is possible, and it shaves three months (well, probably more like one or two given the customization needed) off the project.
- The open source package does what it was intended to do well but is not modular and customizable, and it still ends up taking three months to make it fit within the framework of the entire application anyway.
- The open source package is buggy, nothing works, and it ends up adding three months to the project.
Any developer who’s been around for a while has gone through this process several times and been burned by numbers 2 and 3 enough that they’re now 
suspicious of ANYthing being as simple as plug and play. In fact I generally cringe at the thought of using anything classified as open source for anything other than the intended purpose, generally found on the front page of the project Web site. Most of the time when I set out to use something that someone else developed I’m mentally gearing myself up to fix a lot of their bugs just to make the thing do what it’s supposed to do. I can’t honestly say I’ve ever started using an open source application besides Linux and had it work perfectly the first time I tried to use it. Add the fact that most project generally sit on top of five other projects that dictate the environment, and this results in developers being very leery of using anything that was not developed by them. The truth is, most developers who are building something for free are building it to solve a very specific problem and they’re NOT building it to be the uber-extensible be-all and end-all of software in its category.
The one big exception to this rule is commercial component vendors. They’re usually very good at creating components that can be plugged into your application and will work out of the gate–it’s what they make their money doing, and so it’s in their best interest to make it as smooth and easy as possible to integrate their components into your application. However, most of the time these components don’t contain business logic or the real framework of the application. They’re more along the lines of user interface components or a very specialized segment of functionality that is self-contained and doesn’t need to interoperate too closely with the rest of the application.
So yes, developers are guilty of reinventing the wheel from time to time. However, that is NOT always a bad thing. If you’re building a bulldozer, you don’t WANT to use a bicycle wheel, and if you’re building a bicycle you don’t WANT a bulldozer wheel. Developers are just usually not very good at communicating that fact, and this results in frustrated business owners. Business owners need to realize that not all solutions are created equal, and they don’t all play nicely together. As nice as it sounds to plug a bunch of public code together, sprinkle some pixie dust on it, and come out with the next great applicaiton on the other side, it rarely if ever works that way. You’ll usually hit the wall really quickly, and that’s where the fun stops.
