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!

Leave a comment

UM, have you worked in corporate America? Blaming engineers for this is completely the wrong tact to take. Almost all Engineers want to build good and lasting things, and given the chance that would always be the focus. Managers and stakeholders do not respect engineering, and still want the impossible. I am pretty offended by this blog.

Posted by Chad Augur on Nov 23, 2020 at 01:15 PM UTC - 5 hrs

Leave a comment

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


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (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)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

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

Delivered by FeedBurner