| I actually think the reverse of this is the biggest problem in our industry. From my experience most programmers I've worked with don't understand the underlying mechanism that make their tools work. And when they hit a bug or a problem their tools weren't designed for, the shit hits the fan. And I've seen the reverse of what you're talking about quite a lot ... developers or managers choosing off-the-shelf software with no clue of what they are choosing, just to spend countless resources and important amounts of money ... later to realize that it doesn't fix their problem. But they use it anyway, adapting the problem to the software, just to get a return of investment ... which is the most idiotic thing one can do. But it happens quite often, especially in big companies that get lured by salesmen with promises of greatness. Another thing that happens is that quite often I've seen situations where inventing the wheel is faster than using something prebuilt. That's because software development is not like lego-building. Many times you'll find a module that's close to what you want, but it's not good enough. So you start fixing that, and then you realize that the mismatch is greater than what you thought, and you lost more time than doing it from scratch and keeping it simple. And more to the topic ... the first rule of programming is there are no rules. What works for one project, doesn't necessarily work for another. Also, developers that consciously and constantly try to "keep it simple" and "not to repeat themselves" are doing a pretty good job at not reinventing the wheel anyway. |
I've almost always written something that has less features/worse code/more bugs than a library that would have been a perfect fit. And I did it intentionally.
Why?
Because I learned something new. I've written my own C++ DirectX game library... then went out and used HGE/Goblin 2D. It made me a better programmer because I understood why the design decisions were made because I had similar problems when doing it myself.
I've written my own PHP framework. Why? Same freaking reason. I can look at similar frameworks, CakePHP/Django and quite literally see what it was they were doing under the covers without looking at the source because I've solved the same problem myself.
In the event that there isn't a third party library out there that does what you want, the programmer who is accustomed to look for those first will be screwed. They've never had to make a large system by themselves and they don't understand ahead of time what types of problems they'll run into because they've used other frameworks that have prevented them from making those mistakes.
tl;dr; Using a framework just because its there is similar to a parent coddling a child. When its time to enter the real world they simply won't be ready.
The anecdote here, I believe, is knowing when doing it yourself is a great learning experience, vs a COMPLETE waste of time. Always doing it yourself is stupid, but never doing it yourself is the easy way out.