There seems to be many things in life that can be good and beneficial, but can be made less good or even negative when selfishness is introduced. Software development is no exception. In this post, I look at how selfishness can turn normally positive behaviors into dysfunctional behaviors.
Creative Solutions ⇒ Not Invented Here Syndrome
It's often true that analysis of existing libraries, frameworks, and code bases will lead one to legitimately conclude that new software needs to be designed and written to adequately meet customer needs. That's why we develop software. However, it is easy for a selfish developer to take this too far and waste time, energy, and resources creating something that may be no better than what's already available, only slightly better than what's available, or even worse than what's available. Selfish motivations that can lead to this wasted effort include desire to try something new, desire to stroke one's own ego, and desire for recognition for his or her own greatness in bettering what's already there. To the selfish developer, these motivations may be greater than using a more thoroughly tested satisfactory existing solution.
Polyglot Programming / Best Tool for the Job ⇒ Resume-Driven Development
Polyglot programming is all the rage these days and for good reason. Its advantages include the ability to use the right tool for the job, the ability to learn and adopt principles from one language in development of and with another, and the ability to challenge one's way of thinking about software development. I have enjoyed these benefits from using different languages such as C, C++, Java, Groovy, Ruby/JRuby, Perl, JavaScript, Flex/ActionScript, and so forth. However, as the http://www.polyglotprogramming.com/ site even implies, there are "drawbacks" associated with polyglot programming when it's applied incorrectly.
Bill Burke points out some legitimate issues associated with unbridled polyglot programming in his post Polyglotism is the worst idea I ever heard. As much as I love learning and using new languages, I don't think an objective developer can argue that there aren't any drawbacks to applying too many languages in a single environment. [Incidentally, if someone says anything they are promoting has no drawbacks, I find they are not usually worth listening to.]
The problem comes down to individualistic desire to learn new things and to play with shiny new objects being set against what is sometimes for the greater good of the organization or project. It may be that using three different languages is the best mix for me individually, but if the rest of my team only understands one language well, am I really helping my clients by forcing three languages on them? Is it really fair to our client to expect them to be able to hire enough developers, especially for large projects, that know Java, C#, Scala, Clojure, Ruby, JavaScript, F, Perl, and so on?
This, of course, depends on the situation. Small teams with many developers familiar with or willing to learn a myriad of technologies might have a better chance of making a highly polyglot-oriented environment successful. Even there, though, I expect that years of piling new languages on top of new languages on top of new languages might lead to such a mess that no one is really able to maintain it.
Many clients and organizations are willing to pay for vendors to provide integrated products (that's what Oracle seems to be going after as a vendor) just to avoid cobbling together disparate open source projects. Why would they want their developers cobbling together languages, frameworks, and libraries?
I love learning new languages and the allure of being paid to learn them and apply them is enticing. There are times when it is in the interest of the client or employer and that works well for everyone. However, there are times when I think a less selfish developer might realize that as fun and interesting and value-added as learning a new language might be for him or her, it's just not right to use that language in that environment. Most organizations must live with their developed software and maintain that software for much longer than it took to develop it. Therefore, the best developers understand that maintenance is as important as development and that the organization's long term needs should be considered.
I think developers individually benefit greatly from learning multiple languages. I think organizes and projects can benefit as well, though the application of multiple languages in large environments must be more carefully considered.
Willingness to Try New Things ⇒ Resume-Driven Development
The last issue is not limited to polyglot programming. A selfish developer might be more inclined to use a new library, framework, or third-party product more because it is associated with higher compensation or recognition than for what it can do for the project. It is a good idea to never become so mired in a single approach that one does not improve his or her skills, but sometimes existing skills fit just fine.
Avoiding Needless/Wasteful Experimentation ⇒ Maslow's Golden Hammer
I have just written that selfishness can lead developers to sacrifice organizational success for their own desires. However, it can work in the opposite direction as well. Things do improve in the software development landscape as we collectively learn from our experience. IDEs are generally more productive than not having IDEs. Many abstractions do make building and maintaining applications easier. Some languages are better suited for some situations than other languages are.
A selfish developer may decide he or she doesn't want to learn anything new anymore and just wants to use the approach he or she has always used. This too can be dysfunctional and not in the best interest of the organization. I don't write about this issue as much here because I don't think it's as big of a problem as fed by blogs as is the opposite perspective of always chasing the latest fad. That's not to say it's not a big problem. It is, but I doubt anyone in this trap is reading my blog. :)
Quality / Craftsmanship ⇒ Overextended Cost / Schedule
I have found that it is important to the best software developers to be associated with a high quality product and to demonstrate expertise at their craft. This is generally a good thing. However, there is a point where one is unwilling or unable to ever finish a project because he or she is so driven by the need to have the perfect solution.
Confidence ⇒ Unwilling to Learn / Compromise
I have blogged before that I believe confidence is a characteristic of a good software developer. However, there are times when reasonably experienced people with similar expertise are going to differ in opinion. The confident but selfish developer may be less willing to admit that he or she did not have the best solution or could have been wrong in an opinion. The less selfish but confident developer can acknowledge when someone else has an idea that's better or at least comparable. The more frequent situation is where two designs or opinions are of roughly equal merit. In such cases, selfishness on both sides can lead to an impasse. Unselfishness, especially when existing on both sides, can lead to further discussion, negotiation, and the best overall solution.
Conclusion
It sometimes takes only a little selfish interest, even if it's subconscious, to turn good to bad. Indeed, as I look over my previous post Motivations and Explanations for Poor Software Decisions, I cannot help but think that selfishness is related to nearly all of those. It probably would help all of us to ask ourselves before making some decisions, "Am I doing this because it's best for my customer or employer or because it's best for me?" The (currently) single post available at The Unselfish Programmer blog sums it up well (I highly recommend the entire post): "Successful software is made by being unselfish."
No comments:
Post a Comment