My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
At the beginning of this week's chapter from My Job Went To India, Chad Fowler relates a story about Rao, a "mind-reading" programmer who could pick up on the subtleties in conversations and implement code before you realized you had asked for it.

Both when I first read this, and the second time around, alarms went off in my head: "What about YAGNI?" Why would you implement something that wasn't asked for? If you are wrong, you could be relieved of your position for wasting time and money.

Thankfully, Chad addressed my concerns. It turns out,
We might be standing around waiting for a pot of coffee to brew, and I would talk about how great it would be if we had some new flexibility in our code that didn't exist before. If I said it often enough or with enough conviction, even though I hadn't really put it on the team's TO-DO list, Rao might fill the gaps between "real work" looking at the feasibility of implementing one of these things. If it was easy (and cheap) to implement, he'd whip it out and check it in.
(emphasis mine) Chad also mentions the potential pitfalls in such an approach:
  • You waste time and money if the functionality was not needed
  • You increase complexity of the code base and make "it less resilient to change" if your code forces "the system down a particular architectural path."
  • You could unintentionally make the application "less functional or desirable to the customer."
Honestly, I'd caution against using this advice unless you are in one of the following situations:
  1. You've known the feature-requester long enough that you can pick up on things he's asking for, but hasn't yet asked for. I think you should be really close in this situation. How can you predict otherwise?
  2. There is obviously something missing from the spec, and you have enough experience with similar systems to know it is missing. This might be something like "We need a login system." You can probably safely assume they'll need a way to log out as well, and perhaps even "I forgot my password" functionality.

    The logout functionality I'd almost always toss in (unless requested otherwise). However, even on the "forgot password" feature, I'd consider a couple of things. First, do I know the customer well enough that we've done another application for them and they wanted it? Second, is the budget big enough to where I know they won't be upset if I implement it?
There could be more, but that's what my brain thought of this morning. Of course, in many cases it's just better to ask first.

What do you think?

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

There are no comments for this entry yet.

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