I've come to the conclusion that chasing reuse is a fools errand in typical projects. The bigger enemy is duplication.
I see a lot of copy/paste programming that is not cleaned up by removing the resultant duplication, especially in legacy apps where (a) members of the team do copy/paste because its easy to do without having to understand the full code base, and (b) devs are not given extra time to refactor the code to remove the duplication. This leads to code rot and eventually team rot as the application grows massively in size and grows unwieldy. I've seen applications sold to different potential customers as perfect for their needs as it all 'reusable'. However, 9 times out of 10, because the new customer has 'slightly' different requirements, it could not be reused and instead huge swathes of the existing code base is copy/pasted and changed. To add insult to injury, the original estimates are based on this phantom reusability, and when it turns out not to be reusable, the devs are instead pressurised into working longer hours to try and realise those original estimates. Rakesh On 25 January 2012 21:07, Eric Jablow <[email protected]> wrote: > > > On Jan 25, 7:33 am, "Fabrizio Giudici" <[email protected]> > wrote: > >> Re: the Guice libraries that replaced Apache Commons... what's the point? >> Redundancy in open source is a known problem, basically you don't want the >> extremes: too many similar stuff -> NIH syndrome, while just a single way >> to do one thing -> lack of flexibility. Apart from rare exceptions, I see >> a health distribution of stuff in the Java ecosystem. In any case, it >> seems that this can't have to do with the original paper. This is mostly >> community related, and 1) it doesn't have to do with Java itself, rather >> third parties and 2) how things are supposed to be better in other >> communities? > > For Apache Commons-Lang and Commons-Collections, the problem was > that its contributors never released Java Generics versions. With > Java 6, > Guava functional programming was a strict improvement over Apache. > > However, most of the reusable libraries I've seen are either 'making > Java simpler' , or 'making Java more functional', or 'fixing Date', or > the rare math library. The tasks we all have done many times do > not get into libraries. Okay--I'm not sure we'd ever have a standard > PurchaseOrder class. What about Address? Is there any hope for > a standard version? Note that internationalization is crucial. Each > country has its own address attributes. Postal codes differ; I cringe > whenever I see 'zipCode' in a Java class intended for general use, > and worse whenever I see it validated by the regex \d{5}(-\d[4})?. > > Should the community try to develop classes for common notions? > >> Fabrizio Giudici - Java Architect, Project Manager >> Tidalwave s.a.s. - "We make Java work. Everywhere." >> [email protected]http://tidalwave.it-http://fabriziogiudici.it > > Respectfully, > Eric Jablow > > -- > 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. > -- 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.
