where i work, we have a couple of libs that are shared amongst most (all?) of the projects and a small team is almost solely responsible for those libraries - as a whole, they are treated just like any other project whose customers are inside the company
while it works most of the time, there are some arguing over fixes for a project that breaks another. Usually we adopt the 'right' path and the team responsible for the shared lib is also responsible for fixing the broken project - that was the only model everyone could agree on On Mon, Oct 13, 2008 at 9:31 PM, Weiqi Gao <[EMAIL PROTECTED]> wrote: > > 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/ > > > > -- []'s Marcelo Takeshi Fukushima --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
