On Tue, Feb 2, 2010 at 9:14 PM, Steven Herod <[email protected]> wrote:
> Oh bullshit (re: the article) > > I've seen plenty of cheap stuff thrown together that's perfectly fit > for purpose - once crap reaches steady state, its doesn't matter how > its written, as long as it doesn't need to change. And plenty of > software systems can be written and never need to change for the life > of the business/problem. > > This is another "Programming is an art form, respect my art you un- > greatful bastards" article. :) > *laughs* Of course there are times when someone threw something together and it needn't be changed for the rest of eternity. The problem is to know when that's the case. What I've observed though that there's a discrepancy between the everchanging needs of the users and the willingness of IT to make changes in software. > > *runs for the hills* > > On Feb 2, 7:18 pm, Viktor Klang <[email protected]> wrote: > > On the topic of LoC, please read Uncle Bob's latest:http://bit.ly/cYQlvB > > > > On Tue, Feb 2, 2010 at 6:43 AM, Reinier Zwitserloot <[email protected] > >wrote: > > > > > > > > > > > > > The usual strategy here is to get the dev team together, and decide to > > > spend 1 day (or 1 week, whatever the management cycle is), spending it > > > only on fixing bugs and refactoring so that every single soul on the > > > team reports a negative number for the kloc delta. Act oblivious and > > > wait for the inevitable 'invitation' to management. Then, carefully > > > explain that development is a little more complicated than this, and > > > make sure you're ready with 'before' / 'after' notes, showing how > > > previously horrible, inflexible, unmaintainable crap has been turned > > > into lean, mean, and very pretty code. Explain that if management > > > continues to oversimplify, that you see no other option than to never > > > ever make such improvements again as it would actively count against > > > your 'productivity', and let management figure out that this > > > automatically results in a code base that is going to grind to a > > > complete halt in a year or two. > > > > > On Feb 2, 2:06 am, Christian Catchpole <[email protected]> > > > wrote: > > > > I made the mistake once of telling management that, yes, i could > count > > > > lines of code and classes but it was a terrible indicator. > Eventually > > > > they used it against us. I should have said no from the start. Just > > > > say no. > > > > > -- > > > 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]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > > > -- > > Viktor Klang > > | "A complex system that works is invariably > > | found to have evolved from a simple system > > | that worked." - John Gall > > > > Akka - the Actor Kernel: Akkasource.org > > Twttr: twitter.com/viktorklang > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Akka - the Actor Kernel: Akkasource.org Twttr: twitter.com/viktorklang -- 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.
