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.

> I work in SUPPORT and integration of some pretty complex telecom systems.
> I've seen crap code from every type of methodology out there.

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?

> 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.

> 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.

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)?

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?

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.

> 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.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist