> The top ten percent probably don't reinvent the wheel when they don't have to.
True, but they can invent the wheel because there isn't one, and they can do so in a way that others will find it useful as well. It is a different point than edw519 is making, but what he said made me think about where I disagreed and why.
The purpose of code libraries, is to make everyone more efficient, by solving a problem so others don't have to. If that means a programmer can produce twice as much functionality within a given time frame, or is able to produce any functionality at all where he couldn't otherwise, there is still a net benefit for everyone. This should not be scoffed at; it is the reason why we are able to produce software as featureful and useful as we do. Imagine each of the XFCE, KDE, and GNOME teams having to rewrite X.org all over again, and how much less each of those desktops would have to offer right now if they did. I'm willing to trade useful functionality sooner for less machismo.
But libraries don't always achieve this, and the degree to which it doesn't determines which people will be motivated to create a replacement. If a framework solves a common problem, but does so in a painful, unwieldy, or hard to understand way, some hacker out there will probably think it a better, more efficient choice to just write and use a new solution. It might be a fork of or series of patches to the original framework, or it may be an entirely new codebase -- which of these routes to follow is a judgement call. Nevertheless, it requires what I think is an important distinction, which is the ability to not just understand what problem the framework solves, but how it solves that problem. And not understanding it just in following what each line of code does, but why what steps it takes work. At that point, you end up leveraging a framework far more that relying on it. If something tomorrow were to happen that required you leave it behind, it would be a pain in the ass, but not a brick wall.
There is also the question, more important that the above in my mind, of understanding if you actually have the problem the framework solves, or if you are attempting to shoe-horn. But I worry that might be a bit off-topic of this particular thread, and would probably warrant another 3-4 paragraphs of musing.
True, but they can invent the wheel because there isn't one, and they can do so in a way that others will find it useful as well. It is a different point than edw519 is making, but what he said made me think about where I disagreed and why. The purpose of code libraries, is to make everyone more efficient, by solving a problem so others don't have to. If that means a programmer can produce twice as much functionality within a given time frame, or is able to produce any functionality at all where he couldn't otherwise, there is still a net benefit for everyone. This should not be scoffed at; it is the reason why we are able to produce software as featureful and useful as we do. Imagine each of the XFCE, KDE, and GNOME teams having to rewrite X.org all over again, and how much less each of those desktops would have to offer right now if they did. I'm willing to trade useful functionality sooner for less machismo.
But libraries don't always achieve this, and the degree to which it doesn't determines which people will be motivated to create a replacement. If a framework solves a common problem, but does so in a painful, unwieldy, or hard to understand way, some hacker out there will probably think it a better, more efficient choice to just write and use a new solution. It might be a fork of or series of patches to the original framework, or it may be an entirely new codebase -- which of these routes to follow is a judgement call. Nevertheless, it requires what I think is an important distinction, which is the ability to not just understand what problem the framework solves, but how it solves that problem. And not understanding it just in following what each line of code does, but why what steps it takes work. At that point, you end up leveraging a framework far more that relying on it. If something tomorrow were to happen that required you leave it behind, it would be a pain in the ass, but not a brick wall.
There is also the question, more important that the above in my mind, of understanding if you actually have the problem the framework solves, or if you are attempting to shoe-horn. But I worry that might be a bit off-topic of this particular thread, and would probably warrant another 3-4 paragraphs of musing.