My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Many people see spectacular plays from athletes and think that the great ones are the ones making those plays.

I have another theory: It's the lesser players who make the "great" plays, because thier ability doesn't take them far enough to make it look easy. On top of it all, you could say guys who make fewers mistakes just aren't fast enough to have been in a position to make the play at all.



In the case of sport, one might also make that argument against the lesser players in favor of the ones who regularly make the highlight reel: their greatness lets them get just a tad closer, which allows them to make the play.

In the case of software development, that case is not so easily made.

When developers have to stay up all night and code like zombies on a project that may very well be on a death march, you've got a problem, and it's not solely that your project might fail. Even when that super heroic effort saves the project, you've still got at least three issues to consider:
  • Was the business side too eager to get the project out the door?
  • Are the developers so poor at estimating that it led to near-failure?
  • Is there a failure of communication between the two sides?
A real death march

In saving the project, the spectacular effort and performance of your team or individuals on your team is not something to be marveled at - it's a failure whose cause needs to be identified and corrected.

Handing out bonuses is a nice way to show appreciation for their heroic efforts, but it encourages poor practices by providing disincentives for doing the right thing:
  • No incentive to make good estimates.
  • Incentive to give in to distrations since they "can always just stay late"
  • No reason not to have a foggy head half the day
  • A motive for waiting until the last minute, just to show off their prowess
Handing out bonuses to the individuals who displayed the most heroism brings friction and resentment from those who opted to sleep (especially among those who realize half the work was created by the heroes!). Yet, having only part of the team on board with the near-death march causes the same resentment from the sleepless hackers.

Rewards encourage repetition of the behavior that led to the prize. When you do that, you're putting future projects in peril.

There are plenty of ways to reduce the risk and uncertainty of project delivery - and subtantially fewer tend to work when you wait until the last week of a project - but those methods are the subjects of other stories.

What are your thoughts?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and C++ (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner