Alexey Zinger wrote: > I am currently contracting for a major US corporation. This is my first > gig working in a development environment of this scale and their answer > is basically to have each team responsible for their own code base, but > most teams' code is visible to most other teams. Due to huge variations > in underlying technologies, developer skills and experience, and other > factors, it's not uncommon for a team to treat another team's code as > though it's a rabid dog. That said, the company employs a number of > tactics to improve developer productivity through certain tools that > allow easy customization and creation of very high level apps. I do > wish we had a better maintained library index (library library?). Part > of the problem with most people's dislike for adoption of other people's > code is lack of documentation, not to mention lack of abstraction. I try > to do my part to rectify those in my own code, but it's hard to do since > there's no immediate incentive for any team to make their output > attractive to another team.
Keep in mind that "reusable" code can cost as much as ten times as comparable "non-reusable" code. And in situations like a big corporation with many independent development teams, it's not easy to distribute the cost of reusable code. If developer A created a Customer class for project X, and developer B wants to use the class in project Y, it is usually the case that the class may need to be modified a little bit. A whole slew of questions arise right there: + Who should make the modification, A or B? + What is the modification breaks project X? + To which cost account should the time be charges? + What if the class needs to be changed later (for either project)? + Who are going to be in charge of the code going forward? If developer C on project Z also wants to use the class, it becomes a three way tug-of-war. And pretty soon the whole thing bogs down. The only way things are going to work out is if someone is given the power/oversight over all the projects, and plan for the "enterprise" class library, and make it a policy for all projects to use the reusable code. On the bright side, code reuse is alive and well in most places. If you use the JDK, chances are that more than 50% of code that is run were not written by the project, but by the JDK team. Ditto if you use a third party application framework. And also don't forget that code reuse on a smaller scale is happening every time you do an "extract method" refactoring and your IDE tells you "There are five other places where exactly the same code is present, do you want to replace those with the refactored method?" -- Weiqi Gao [EMAIL PROTECTED] http://www.weiqigao.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
