My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
When someone starts complaining about customers who are making silly requests, I normally say something like, "I know! If it weren't for those damn customers, we'd have a perfect program!"

There'd be no one using it, but hey - the application would be sweeeeet.

This week I'm going to diverge from Chad's book on how to save your job. That's mostly because I don't have the book with me, but this has been on my mind the last couple of days anyway: the fear of success.

I've noticed it in myself and others from time to time - inexplicably sabotaging opportunities to succeed. I try not to listen to that voice now if I can help it.

More recently, I've started to notice it in companies and customers as well - groups as opposed to individuals. I've started wondering if reluctance to "go live" until the product was a symbol of perfection fits in with this phenomenon.

What can we do to help them get over this irrational behavior? If they continuously request those trivial changes and never go live, the project has failed. Do you think they will blame themselves, their ideas, and their actions? No, they will blame you, and find someone else to work with next time. So you may have been paid for your time, but it still impacts you negatively.

Don't get me wrong - sometimes there are good reasons to wait to release a product or service. Sometimes, you don't need to DIFN. However, the fear that your customers won't know to look under "output devices" to find a subcategory of "printers" is probably not on that list of reasons. Someone has been using a product to great advantage for many years and you want to "wait until you finish the last bit" to sell it as a whole to others - also probably not on that list. You want the login on the left hand side instead of the right?

After a week of such changes, it's one thing. Six months? GMAFB.

Perhaps you'd have been better off letting your customer's use it to see if they got confused, preferred blue links to red ones, or even happened upon an idea to make the application flow better.

So what does make the "OK to wait"-list? The fear of underwhelming an audience with your unfinished product would, especially if you're get to show them exactly one time. I can't think of much else that does. Can you?

So the point is that you need to get over the fear of success. Stop snatching defeat from the jaws of victory. Let a good thing or two happen. Help your customer's get past their fears.

Changing ourselves to recognize that fear and ignore it is something we can all do. Looking at our customer's excuses to keep the product in the warehouse from a fear-of-success angle might provide a way to relate to them instead of scoffing at their incessant requests for frivolity.

Success is staring you in the face. All you have to do is stick your hand out and embrace hers. Why do you turn and run away?

I'm exploring this space for the first time. Obviously, I have a lot of questions and very few answers. If you've got either of them, let me know in the comments - it's always appreciated.

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

Fear of success (and failure) often manifest in procrastination. You'll try to do anything except the things that will get the project done. I've fallen victim on many occasions. I'm currently working on a couple of ways to defeat this type of behavior:

(1) Your mind perceives any type of fear as reality. It doesn't matter if this fear is real or imagined. It's o.k. to be afraid when someone is shooting at you because that is a legitimate fear. However, fear of success or failure aren't rational because both events take place in the future. Since no one can predict the future the fear is not necessary.

I think the best way to deal with this is looking at your irrational thinking. You can do this by writing down your fears on a piece of paper. Create a column a label it fears. Now write down everything you automatically think of when worrying about a project. Next, in the second column, think rationally and give reasons why your fears are not justified. For example, you may think: "If I screw this up, I'm going to lose all my clients." Your rational response would be: "I've made mistakes in the pass and I've never lost all my clients. Even if this project is a failure, it is highly unlikely that I'd lose everyone."

(2) When you worry about success or failure, have a look at your past success and failures. You have to prove to yourself that you've had ups and downs in the past and it has never turned out as bad as you thought it would.

Something I've been doing lately is getting into that "just do it" attitude. The way I procrastinate most often is to go overboard on research and planning. I tend to overplan and then I keep revising. I also delay to do research on new technologies. The only way I've been able to get around this was by just jumping straight into the code. I'm not saying that you shouldn't do any planning, but get a rough plan in place and start coding. You can always refactor later!

Posted by Brad on Dec 07, 2007 at 05:32 PM UTC - 6 hrs

Good topic !

the underlying reason of such a "let´s wait, we´re not yet convinced" behaviour can in fact be driven by what artists know as "stage fright", and releasing a complex website or a complex piece of music to the public is somewhat similar in this respect :: the bigger and complexer it is, the longer you had to "rehearse" for hopefully getting it accepted by your audience -- however the DIFN approach will have a positive side effect, because the earlier you release whatever form of art, the less time you have for building up your array of "what if" fears.

Funnily enough I never had to face this problem with customers who are artists themselves -- it´s always been the ostensible hard-boiled business-type folks who were affected by this sort of fright the most.

Posted by Günter Schenk on Dec 07, 2007 at 05:56 PM UTC - 6 hrs

On the specifics on when to launch:
I set a simple acceptance criteria for new project launches. Is it better than what is up now? If it is, we usually try to launch.

On the more general question:
We tend to build our psychological flaws into the software we build. Whether it's customers with the requirements, project managers with their processes or coders with their scripting, a completed application is often strongly influenced by the psychological state of the people involved in developing it. It's a fascinating study (especially as I was a therapist for a while - a long, long time ago). Maybe I'll do some postings on this next year . . .

Great topic - thanks for bringing it up!

Posted by Peter Bell on Dec 08, 2007 at 06:40 PM UTC - 6 hrs

Thanks for all the great comments everyone.

@Brad- I like the idea of putting it all down on paper as a lead in to discussion. I don't think there is conscious-worry in the clients or companies, though, but it is a subconscious fear. I might try that exercise to see if it will help them recognize it.

@Günter - I'm glad you brought up that connection - I had never thought of it that way. Having been in a band myself, I definitely can see the similarities as I recall the past.

@Peter - I'd definitely read those articles a couple of times if you happen to write them. I'll be on the look out. =)

Posted by Sammy Larbi on Dec 10, 2007 at 11:01 AM UTC - 6 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