On Tue, Feb 2, 2010 at 9:49 PM, Todd Costella <[email protected]>wrote:
> Somewhat related to this discussion is the excellent post by Lukas > Mathis: http://ignorethecode.net/blog/2010/02/02/removing-features/ > Now I have to stop and call BS :) I'm all in favor of removing features. I'm not in favor of saying no just because. When a customer comes with a request, what needs to be done is to talk to the customer, elicit the real need, and make a fair proposal on what it would take to fulfill that need. This includes having to redesign things to fit together naturally. The example of the Swiss Army Knife is somewhat contradictory, as the knife is designed to be extensible. In my mind, a better example would be to first be asked to produce a kitchen knife, then when that's done, asked to retrofit it with drilling capabilities. There are 3 possible solutions: 1) Say no 2) Duct-table a powerdrill to the knife 3) Design a device that has both cutting and drilling capabilities and does both great Now, saying no could possibly mean that the customer is losing out on a great business opportunity. Duct-taping the knife to the powerdrill WILL get someone hurt. Redesigning will take more time up front, but possibly save a lot of time in first-aid maneuvers and will most likely assist the customer in making his business successful. I'm in no way saying that the customer is always right or even knows what his real need is, I'm just saying that there's value for both you and him to sit down and see how you can collaborate. > > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Robert Casto > *Sent:* Tuesday, February 02, 2010 1:43 PM > *To:* [email protected] > *Subject:* Re: [The Java Posse] Re: How to measure lines of code in Java > > > > Does it fall to us to educate management though? I find that long term > issues tend to be overlooked since the immediate need is great, here, and > now. Let tomorrow fend for itself. > > The problem that IT tends to pay big time from this approach, not those who > make the decisions. > > On Tue, Feb 2, 2010 at 3:35 PM, Viktor Klang <[email protected]> > wrote: > > > > 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]<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. > > -- > 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.
