Bridging the Gap for the Average Software Developer
One of my earlier posts about the ignorance of copyright protection on the ideas embedded in software generated a couple of comments, albeit anonymous comments.
I will take another stab at this.
My experience in industry, from purely mechanical product oriented design to software-intensive electromechanical design, is that truly innovative people are few and far in between. In a design group of 15 to 50 very good, talented, and experienced engineers, there only needs to be one super inventive person. The inventive person has the vision of the project and merely lays the groundwork on which the rest of the team builds. In many cases, the groundwork may be built upon for years after the person leaves the company.
This inventive person is a very rare breed, compared to the average engineer/designer/software developer. The inventor is the person who sketches out a radically new architecture of a product and sees the value of the ideas in a much different light. Compare this to the average engineer/designer/software developer.
The average engineer/designer/software developer is given a specific task to complete. In some cases, that person has some leeway in how he or she structures the solution, but in general, it follows a style or convention laid out by those who went before. This is true, in my experience, in aircraft design groups having 5000 engineers as well as small design teams of a dozen or fewer developers.
The inventive person, when looking at the group’s products from a business viewpoint, can see the business value of the ideas. However, the average engineer/designer/software developer may not. Usually, a bold new design is met with enthusiasm by the average person on the design team, but after a few months or even years slogging it out on a project, the average person may lose sight of the inventiveness and “coolness” of the project, getting to the point where the “inventive” areas look “obvious” in hindsight. In many cases, the accolades and bonuses may go to the inventors, with the average person being left out in the cold. Often, the person doing the average task believes, and sometimes rightly so, that he or she could be and should be doing the visionary work.
However, the average person on the team may not have the vision to understand the impact the pure ideas themselves have on the project. After working on hand-me-down ideas for years and maybe decades, without ever having the opportunity to be the architect and innovator, this person may come to see all ideas as meaningless. For this person, especially in software development, the value is not so much in the idea itself, but in the elegant representation of someone else’s idea in his or her code.
The software industry has some peculiarities that makes aggravates the problem. One part of the culture, that I alluded to in my other post, was that there is a great emphasis on portability, re-usability, and maintainability of code, which detracts from the idea it represents.
The point of all this is that there is a cultural pull away from looking at the economic and business value of the idea in the software industry. After all, patents are nothing but a business tool and should be viewed with a business mindset. Sure, well written, elegant, and reusable code is a business asset, but it has a much smaller business impact than the overall purpose and idea of the product. Every person in a business enterprise has tasks that help the business move forward, and each person sees how their piece fits in, but not necessarily appreciate the contributions of everyone else.
There are far more “average” software developers than there are truly innovative ones, and I would guess that the ratio is 100:1 or greater. They can speak with a loud and raucous voice, especially when whipped up by a few leaders that can capitalize on the average developer’s potentially unhappy relationship with the truly inventive people.
To truly understand the impact of the ideas, and why patent protection makes so much more sense than copyright for protecting the ideas, the average developer must look at the business logic and market forces that put value on the idea. This is the education that still needs to be done in the software community especially, but also in all research and development labs.