Note: I'm sick of gluing gender-specific references together all the time, so I will refer to gender-agnostic persons as "it". An interesting (but perhaps unnecessary) discussion has arisen in a private mailing list of a technical community i belong to. The thread starter was looking for ways to protect "intellectual property" between colleagues in a software development team.
Source code produced by Developer A (DevA) and checked-in (saved) to Source Control and be read and modified by Developer B (DevB) if necessary, and has the right permissions to do so. If DevB finds some useful code that DevA put in great effort and time to produce, and just copies over into its own work, DevB reduces its own development time to great effect. Come worse, if DevB blows its trumpet and steals credit, it makes it appear to be a better developer than DevA, who may have remained slient or ignorant over the issue. DevA could appear to be a slow developer when in reality was the one producing the components saving others' time. Yes, this is called "plagiarism" back in the school days.
From the responses of some members, it certainly
is happening in this world. Sad enough. Let me stand firm and say that DevB is scum. That's the nicest I can put it. Might as well claim to have painted the ceiling of the Sistine Chapel (this is just an extreme example). I have always believed in giving others credit when I make use of their code. There is
value is mentioning how you picked up code from various sources and merged them into workable logic for your own case.
However, as many others have pointed out (and my agreement goes with them), the root of the problem is really at the
institutional level. All source code is ultimately the property of the company or organisation, not the individual developers. To have developers snooping around and copying, and thereby
duplicating, code is just plain bad practice. There is a lack of coordination at the team level of pile such code into highly reusable Application Blocks or Patterns that everybody can benefit from.
This suggests a failure on the Team Lead's, Architect's, Manager's, or even Management's part. I sincerely believe culture always starts from the top - leaving it to evolve by itself from the bottom is
deliberately asking for trouble - just ask management committees of prisons.
The boss (whoever is in-charge at whichever level) should preach and
enforce, not encourage, the practice of forming these type of copiable, repeatable code into libraries of reusable components. Developers should be appointed and empowered to develop different aspects that contribute to application development. Everybody can be the explicitly clear who is repsonsible for which component/library. One's accountability and credit is then clearly visible and measurable.
The above paragraph, of course, assumes the boss is knowledgable in software engineering practices. If your boss cannot perceive this... what can I say.... the number of under-qualified bosses in this field alone is simply staggering. Godspeed. If you happen to find yourself in, or close to, DevA's shoes, and are concerned with your career progression, my advice is to
Always report to everybody what you have been working on, or completed I do not mean trying to be snort and boastful about it. No. Never engage your pride in that manner. You should approach in a way so others will no longer be ignorant to what you work on. This eliminates any doubts or suspicions they may have. But more importantly,
- They can see for themselves what they can make good use of, and have them reference your library, saving them time.
- Provided they are interested, they can give valuable feedback on how to improve your component, especially in abstracting it if it still isn't good enough to be used across different modules or applications.
When such a strong culture of active code identification and consolidation flows within the group, the fundamental issue of plagiarism effectively becomes a non-issue.