I think the emphasis of using usage data to figure out exactly how folks are using your app is a good measure. It's nice to at least have some backup when someone says "we need to update blah because of ..." you can at least say well four people used that feature last year so if you really want it, it will cost you x*<some pain factor> where <some pain factor> is an estimate of your pain and suffering for having to support the updated feature in the future.
________________________________ From: javaposse@googlegroups.com [mailto:javapo...@googlegroups.com] On Behalf Of Viktor Klang Sent: Tuesday, February 02, 2010 2:03 PM To: javaposse@googlegroups.com Subject: Re: [The Java Posse] Re: How to measure lines of code in Java On Tue, Feb 2, 2010 at 9:49 PM, Todd Costella <todd.coste...@entero.com> 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: javaposse@googlegroups.com [mailto:javapo...@googlegroups.com] On Behalf Of Robert Casto Sent: Tuesday, February 02, 2010 1:43 PM To: javaposse@googlegroups.com 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 <viktor.kl...@gmail.com> wrote: On Tue, Feb 2, 2010 at 9:32 PM, Robert Casto <casto.rob...@gmail.com> 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 <viktor.kl...@gmail.com> wrote: On Tue, Feb 2, 2010 at 9:14 PM, Steven Herod <steven.he...@gmail.com> 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 <viktor.kl...@gmail.com> 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 <reini...@gmail.com>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 <christ...@catchpole.net> > > 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 javapo...@googlegroups.com. > > To unsubscribe from this group, send email to > > javaposse+unsubscr...@googlegroups.com <mailto:javaposse%2bunsubscr...@googlegroups.com> <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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com <mailto: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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com <mailto:javaposse%2bunsubscr...@googlegroups.com> . 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com <mailto: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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com <mailto:javaposse%2bunsubscr...@googlegroups.com> . 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com <mailto:javaposse%2bunsubscr...@googlegroups.com> . 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com <mailto: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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
