Hi Rakesh, excellent point on reuse. How do your customer measure reuse?
regards andreas On 25 Jan., 22:20, Rakesh <[email protected]> wrote: > 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 > > athttp://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.
