On 4/13/07, Vitaliy wrote: > > Nate Duehr wrote: > > > Welcome to the church. Agile is just another methodology/religion. > > Debatable. > > If I remember correctly, last time we had a discussion on the subject, it > was decided (decreed by James? -- doesn't matter..) that religion must > have > a deity. LOL. Nice. I think it's reasonable to say that some methodologies are more conducive to > producing crap code, no? Can you really NOT follow ANY methodology? True. Crap is crap. Or as a co-worker once said, "I give up, all we can do is polish this turd." Once you get beyond something a single coder can write, you need at least a framework that everyone works from. > The ONLY thing I KNOW works 100% of the time, is tying whether or not the > > software WORKS to the engineer's WALLET. > > No amount of money will ever make a bad programmer produce good software. > So > obviously, it doesn't work 100% of the time. What works is *hiring* good > programmers in the first place, and motivating them to do a good job. Great point. This article does a pretty good job of describing how not to hire the bad ones: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html > Here's how it usually works in most companies: > > Engineer hits ship date... bonus... bugs and major problems with that > > code... oops... we already gave the engineer a bonus. BAD BUSINESS. > > > > How it SHOULD work: > > Engineer told up front that bonus based on number of major/minor bugs in > > system after release. Bonus paid out over time. THEN the time > estimates > > and ship dates are set. Manager and Engineer learn to figure out how to > > properly negotiate ship dates or they kill each other trying. Then the > > product is written/released and performance over time is tracked by the > > SUPPORT department, not the Engineering management. Bonus or lack > thereof > > is based on customer and support staff pain levels caused by bad code. > > Have you ever seen this done anywhere? The problem I see is metrics. No, which is why I believe it has merit. (GRIN) Ultimately in a support group you're paid by only a few factors, and one of them that's objective is whether or not you know how to fix things properly and/or provide workarounds in a way the customer is not upset. (Bigger picture, you're paid if customers keep signing service contracts. Ironically if the code were perfect, and easy to use/install, the service contracts would cost less and there'd be very few support people. When engineers screw up, they guarantee I still have a job... so, by suggesting ways to make our products permanently better, I'm technically working myself out of a job, right? This is one of the horrible deep Catch-22's of the software support industry.) But engineers are rarely paid for what they actually do, they're paid for release dates... release junk, you still released ahead of schedule, and you still have a job and a bonus... as long as you met the general requirements. Many times engineers can even convince managers to drop important requirements near the end of a project, because guess what... the manager's bonus is based on the release date too... That's just wrong. Do you assign a fixed penalty (per bug), or go by the percentage (X bugs per > Y lines of code)? Does it matter what kind of code (simple, or involving > complex algorithms)? Simple. Did it work for the customer? (The same metric any small developer or business uses daily to prioritize their work, or they go out of business.) All the other metrics, in the end, don't matter. Does the support department have an objective measure of the impact of a > particular bug on the product's performance? Or does the Engineering > department go without a bonus, simply because someone in the Support > department is having a bad day? Come now... not just one person would determine this. Have you seen the rediculous number and types of metrics most large support departments have these days...? Ticket systems have grown into their own world of multi-million-dollar systems (after you pay all the consultants to upgrade the thing because it's so complex no one in your own organization can even work on it at that level). A management review of the open issues would easily quantify the open tickets for customer impact. Major, minor, and don't care... but even minor stuff will ALWAYS come back to bite you later, I've learned. Almost every single time I've heard an engineer say, "We couldn't get to that in this release", the customer comes screaming back later asking where it is. People in all three groups (engineering, support, and customer) aren't as dumb as many engineers would like to think. If the engineer and the support person both agree that the customer is probably going to want it, the customer will. I think that one of the solutions is to have someone from outside both the > Support and Engineering departments decide who gets the bonus. That would > assure at least some level of objectivity. Sure. Fine. Sales? LOL! Technicians peer's should be technicians. But that's just my opinion. > People only pay attention to detail if they're motivated to do so. Taking > > money away (or not giving it) is an incredible motivator. > > Money is not the only (and not the most important) motivator. Surveys > consistently demonstrate that it's not at the top of most people's list of > things that make a good job. Salary offered must be competitive, but > things > like "interesting work", "a good boss", and "growth opportunities", tend > to > be higher priorities than money. They only say that AFTER they have a job and are getting paid. Ask anyone without a job. Maslow's Heirarchy of Needs skews those surveys, because they only ask those survey questions of people who already have jobs. The few that will stand on principal and not work because they want something "more interesting" when they can't pay the rent, are few and far between. :-) Nate -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist