On Tue, Feb 2, 2010 at 9:32 PM, Robert Casto <[email protected]> wrote:
> Exactly. Customers always want more. There is always something else that > can be done. > > IT just says yes even when it makes no sense. We need to do a better job of > educating users that there are costs associated with their requests. Not > just to make the change, but to be able to maintain it, document it, test > it, etc. These costs are completely ignored at times and they come back to > haunt IT, not the people requesting the changes. > Absolutely. Usually there's someone who's focused on price, but what's really interesting is the cost vs. benefit. There are some really strange misconceptions out there about costs of software, and cost of ownership is almost always underestimated. > > On Tue, Feb 2, 2010 at 3:26 PM, Viktor Klang <[email protected]>wrote: > >> >> >> 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]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > > > -- > Robert Casto > www.IWantFreeShipping.com > Find Amazon Filler Items easily! > > -- > 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.
