* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!


» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)


Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Motivating Programmers

Hi All,

I've managed to collect a group of 3 programmers that are working on a specific project.  We're within about 3 weeks of being completed, if they work hard.  However ... they're not.  They're getting tired of staring at the same code, making revisions, and refactoring, for about 10 weeks (two of them), and more than 6 months (the other one).  They've kinda quit talking and working as a group.

If it was me, I'd still be driving along, because, of course, it's my product.  It is, however, a product that they chose to work on, and the group used to be very smooth (they didn't talk then, but they did at least communicate enough to work together).

We're past the 90% of fun (building the initial), and 90% of the hard work, we're down to the last half of the last 90%.

They each are driven by different factors .... and I'm sure that one of them would be driven by a lot of carrot :-)  Dangling a chunk of money in front of him would work.  The other two could care less about the money.

Oh yeah, they're all incoming male college freshmen.  And extremely talented -- exceptional even.

Anthony Presley Send private email
Tuesday, August 15, 2006
the biggest problem is that their goal is not to get the software out of the door.

i have this problem too.  it is really fun starting a project.  finishing it doesn't rank that high on my list.

the owner of the company took me out to lunch to just talk about the project.  it opened my eyes when the owner said "i'm really excited about where we are and where we COULD be."  ...and "it's amazing how far you have come."

getting the programmers excited again shouldn't be about getting them to program/finish the project.  but, getting them pumped up about the ego trip they will have when their software is out the door.  talk about the next big step.  pamper them as a reward for getting close to the end. 

when i'm in these shoes it feels like the end of a semester at school... i'm just ready to get out.

focus on getting them as anxious as you are.  programmers are expensive for these situations alone.
Tuesday, August 15, 2006
Some wise person once said ...

"The first 90% of the project takes 90% of the effort, the last 10% also takes 90% of the effort."


Ray Smith
Ray Smith Send private email
Tuesday, August 15, 2006
"if they work hard"

Is there any reason they should stress themselves out to meet 3 weeks?

If not, then let them take it at a fair pace if they're sticking around. If they're just interns and you don't want to hire them, feel free to push them and burn them out.
Josh McFarlane Send private email
Tuesday, August 15, 2006
Incentives work:
I used to use consumer electronics: digital cameras, ipods, rc toys etc.
Another thing I used to do is to give them something that they would'nt do for themselves.  I used to send them to a massage place to be pampered.

I would also sit them down and talk to them about maturity and responsiblity if things get really critical.

I hate talking hindsite but when you get seasoned programmers your also getting someone who hopefully finishes their work.
Tuesday, August 15, 2006
Take a break.

Surprise them one day at the office with a scheduled outing. Go to a ball game, or into the city/woods/wherever.

Don't talk about work, either. Just a day to refresh.
Tuesday, August 15, 2006
Here is my 2 cents:

Use an Agile Development Methodlogy.
(You can choose between quite a few, but for a small team eXtreem Programing can do fine. )
This methology aligns your busniess with the development team and gives all developers the same goals.
It allows developers to swich the code base quickly and you see real working software in progress every 2-3 weeks.

Just remember to implement the methodology in a agile manner, in small incremental steps :-)
Eli Lopian
Tuesday, August 15, 2006
Where was management?
Tuesday, August 15, 2006
Thanks for the responses.  Jeremiah, you're right -- finishing the project isn't really their goal.  They're all about as sick as they can be of this particular project, because, as others have mentioned (and I did in the original post), the first 90% is fun [isn't that what all the blogs show ... that the ideas and prototyping is fun?] ... the last 10% is also 90%.

IMHO, Programmers are about as fickle as sales people in managing their egos (yes, programmers, including myself, have egos).  They've got to be inflated, a lot.  About three weeks ago, my guys were hitting the project "hard" (they're paid well), and my business partner and I (on this project) took them out to Best Buy, gave them about $150 each, and said "Have fun".

We explained that they'd been working hard (they had), and that we appreciated it, and hopefully, the completion of the project would lead to even more.  About a week later, they ground to a halt.

anon, the incentives do work, you're right.  I know that the "ring leader" of the group (who has stepped into managing the group) is highly motivated by money, and incentives do work very well with him.  However, the other two drag their feet if they don't think the work is interesting.  And they could care less about the monetary results.

I'm actually very much agreeing with the Agile Methodology.  I've used team-programming before, and it worked well.  I tried once with two of these three (prior to the summer), and they freaked out.  Both hated it.

As for Handyman .... gee, I dunno.  These are three of my six or so programmers, and everyone else is working on other projects.  They're doing very well, as a team, even.  One of these three is still doing just fine, but as a team, they've all fallen apart.  Two of the three HATE the platform (yes, Javascript DOES suck), and they all think that moving to a new project would make life interesting again (it would!).

The trick here is to get them through the last 10%, and then (as they've been told) they have some paid time off.

We shall see.

Again, thanks for your comments.
Anthony Presley Send private email
Tuesday, August 15, 2006
Your problem is that you mistook their "exceptional"-ness as talent, when really it was exceptional potential. Freshmen never make exceptional employees straight out of the gate, they have to have their egos stamped out so they become project-players and team-players.

Time to be tough with them.
Colly Moddle
Tuesday, August 15, 2006
You could give a little "tough love" and say that if they don't complete this project on time, there won't me a new project(at least not with you).  After all, if they can't complete this one, why trust them to work on another?
Honu Send private email
Tuesday, August 15, 2006
> We explained that they'd been working hard... 
> ...completion of the project would lead to even more.

Pressure, pressure, pressure, but no release. It sounds like they're constipated. There has to be some relief from the pressure at some time or things get very uncomfortable.
Tuesday, August 15, 2006
Have you asked each of them "why?" Just ask each of them why but not in an office setting since that would just make them put up a wall but rather talk to them in a more relaxed environment as someone suggested go to a ball game or even to  just walk around the city (if possible). It's tempting to have a reply when they tell you why but this time resist and stew on what they tell you. Sift through it and see if they are right or not. Once you have figured out why they are behaving as such, address the issue.
Phillip Flores Send private email
Tuesday, August 15, 2006
If they're new meat they haven't really had the feeling of shipping a product and seeing it in the real world help somebody. That's what gives me the biggest kick. Don't get me wrong. I like learning new things and there is always the draw of solving interesting problems but it is always such a rush to go out into the world and see something you made sitting on somebody's desktop helping them through their day.

I think the inverse of that is why most programmer's get so fired up about not wanting to ship crap. Having been involved with a couple of projects that were total garbage I can't tell you how horrible it is to continually have to apologize for the complete piece of shit that is sitting in front of a user. Or maybe you guys know that already :-(

Not knowing your programmer's I figure you have one of several options open.

1. Scare them. Start throwing shit around the office. Yell. They are just kids. There is a great scene in Bull Durham where this is shown to be quite effective.

2. Take a break, as others suggest.

3. Start planning for the next release. Make it clear (but don't be an ass about it) that you can't start working on the new stuff until version 1 gets shipped. Maybe they can't see beyond the end of the project.

Programmers are a fickle lot. I know from personal experience. Opinionated, too. Especially the new ones who don't have a whole hell of a lot of experience.

Also, what makes them exceptional? Are they just smart? Do any of them work on open source projects? Have any of the projects they've worked on approached a completed state? Are they used to being spoon fed assignments like in school or do they have some real world experience?

Exceptional as they may be I'm sure they have a lot of maturing to do. I vaguely remember being a 17 or 18 year old male. The last thing they probably need, assuming they are anything like I was, is to be told how great they are. Hell, at 18 I KNEW I was the best thing since sliced bread. Instead of babying them you may just have to take them out behind the woodshed and smack them around a little. They've probably heard their whole lives how smart and wonderful they are. Knock 'em down a peg or two.
Bart Park
Tuesday, August 15, 2006
>>>...incoming male college freshmen.<<<

Don't these guys have classes to worry about?  Or are they recent high school graduates who will be going to college this fall? 

Anyhow, this project can't have been too important to you considering that you hired the cheapest programmers you could find.  It sounds like they are good at programming but not so good at being developers.  (Eric Sink has an online essay no this.)

Hopefully, it will be a lesson to you.  Now you need to spend a lot of time with these programmers teaching them what it takes to get a product out the door.

>>>Go to a ball game...<<<

Threaten to take them to a ball game?  Be sure you pay them for their time.  After an afternoon of this, working on your program would be a pleasure.
Q7 Send private email
Tuesday, August 15, 2006
Another couple of thoughts:

I worked with a programmer once that surfed the net, downloaded junk, ran around the office and pretty much did not get anything done.

The PHB was smart about this, actually.  He let it happen for a couple of weeks when finally he sat him down and said "When I'm paying you to program and all you do is mess around, then you are stealing from me. Did you know that I think of you like this?"

Talk about an eye opener.  Your programmers are there to get stuff done.  Right now it doesn't sound like they are.  If they are college kids, they are used to messing around and not having any direct consequences. 

I've seen the PHB give this speech to many people.  It works most of the time.  Sometimes they get mad, but they know he is right.  Others, they listen and get themselves motivated again.

The real problem here:  They don't realize that they are there to get stuff done.  Accomplishing their tasks are not their highest priority. 

My father has always said "Performance builds trust."  Tell them they are not performing, so what does that mean?  Can you trust them to be a good programmer?
Tuesday, August 15, 2006
You guys sound like the worst managers. "Yell at them, curse, scream, burn them out, tell them they are stealing from you".

What are you talking about? These are not slaves, they are human beings.

Anyway, to the dumb manager who posted this question. +1 to QZ above. Obviously, you have no clue how to manage a project else you wouldn't be in this situation. You're also a cheapo for not hiring a real programmer and choosing college grad interns instead.

Your end product will look just as good as the college grad interns you hired.
Tuesday, August 15, 2006
Some wise person once said ...
"The first 90% of the project takes 90% of the effort, the last 10% also takes 90% of the effort."

From my personal experience:
"The first 90% of the project takes 10% of the effort, the last 10% takes 90% of the effort."

It is hard to be motivated when you doing last 10% of job for a long time. Even Joel wrote so many good things about the intrinsic motivation in this case I think extrinsic will work too.
Katerina K. Send private email
Tuesday, August 15, 2006
  The irony in your post makes me smile.

re: the topic at hand:
  My management style is definitely toward the calm and friendly sort.  But I've seen my particular college intern take advantage of me rather than respond to my style the way I would have hoped.  He decided not to show up for work.  For a week.  Each time I called him he assured me he'd be in for work the next day.

So I can either fire him and be glad to be rid of the problem, or I can be firm with him and hope he cleans up his act.  The benefit of being firm is it's not just good for me -- it's good for him, too.  Much better to get "a good talkin' to" now rather than get fired from a "real" job later.  So far he's responding well, and I think he's grateful to still have his job.  He says he loves the job and feels bad when he screws up, so I am hoping for sustained improvement.

Sorry for the anonymous post - would prefer that my intern not identify this. :)
Anonymous This Time Send private email
Tuesday, August 15, 2006
If you have a next project, and it is as exciting as the first one, then let them know that to move on to the new project they will need to complete this one.  The earlier is done the sooner they move onto the next.

This sometimes motivates programmers.
Tuesday, August 15, 2006
Like PBR said.  You could figure out what the next project is, have a meeting about it, get their ideas, wind them up.  Then don't let them work on it until the current project is shipped.  You may have to check up on them.  :)

You might also think about how post-release support will be handled, and get them to sign off on how that's going to work in advance--they're not going to want to do maintenance if there is a shiny new project to work on, better have a plan.
Matt Conrad Send private email
Tuesday, August 15, 2006
"Use an Agile Development Methodlogy."

Changing to a completely new methodology 3 weeks before a deadline is a GREAT strategy.
Tuesday, August 15, 2006
Your original post stated that these were "incoming college freshman".  That tells me that they just graduated from high school.  If that is true then you do have a problem in as much as I would doubt they have ever had a product shipped.  This totally explains why they no longer want to work on the "old" stuff and go on to something new.

If you plan on keeping them once they start school then I would suggest that you take your best two from another team and swap them.  If you dont plan on keeping them, then I would suggest you let them go and bring in an experience consultant to finish the project.  It would cost you about the same in the long run and you would have less headaches.

In the future I would also suggest that you dont have two jr level people on the same project unless you have a senior person to mentor.

These two individuals are too green to understand the entire software development process.  They may be talented to write code but not to get a product out.  Yelling at them is not going to do any good cuz they have no clue.

My 2 cents
Tuesday, August 15, 2006
"anon, the incentives do work, you're right."

They do?  You just told us that three weeks ago these guys were working hard.  You gave them an incentive.  Now they're not working hard.  And people are suggesting more incentives?  Maybe the incentive was the problem in the first place; incentives are addictive, and they devalue what you're working on, through the implication that it must be boring or you wouldn't need an incentive to do it.

People work hard on things that are interesting and valuable.  Consider that they probably don't recognize the value of what they're working on now.  It feels like the "real" work is done, and they're just cleaning up crappy loose ends.  When I get to this point in a project (and I always do), one thing that helps is to step back, pretend to be a user, and start making notes about what needs doing.  Another thing that can help is having one or two other people, not directly connected to the project, do this.

Either way, you end up with a list of to-do items.  Without this, you end up with just vague notions that stuff needs to be cleaned up.  Having a list gives a psychological advantage because you can see how close you are to the end of the list.

After making a list of the issues, you might even try putting a big posterboard on the wall with a bar showing how many issues are resolved, and gradually filling it in all the way across as issues get completed; anything that will give them a sense that they're accomplishing things, and that there's an actual end to the project.
Kyralessa Send private email
Tuesday, August 15, 2006
The post by Kyralessa got me thinking.  How about having them give a demo of the product to the rest of the company.  Part of that would be having them identify the pieces that need to be cleaned up.  The fear of doing an embarrasing demo for others might help them see the big picture.

Good Luck.
GoDogGo Send private email
Tuesday, August 15, 2006
Thanks for those of you with supportive comments ... and those of you less supportive (I guess I'm the "dumb manager" who needed to "learn a lesson", by being a "cheapo" and not hiring "real programmers").

I am absolutely the one who hired these three, who are working on a small project for us which I would prefer to have wrapped up sooner rather than later, but is not of the highest priority.  It's certainly not our bread winner.  It's more of a project Aardvark, of which one of them worked off-and-on for about 6 months, the other two just started in June (when they all started full-time for the summer).

As such, my question was posed in the context that I placed it .... what would you suggest to motivate programmers at the tail-end of a project?

I believe Joel recently posted on some management tactics, including carrot vs. stick, as well as others.

Some great suggestions on motivating programmers (good or bad programmers) and people in general got posted here .... so I'm quite excited about some new ideas on the boards.

I took some of these ideas, as well as our own previous management methods (I like to use equal carrot and stick, along with a lot of "buy in" from the staff) and we had a great sit-down today.

I will let you know when the product is done (their portion is set to be done in 3 weeks, and probably another 3-4 weeks of some final design and integration work after that by one of our senior developers).
Anthony Presley Send private email
Wednesday, August 16, 2006
Can I ask how much you are paying them? I remember working programming jobs in college for $5/hr and I have to say I didn't really feel all that motivated to finish after doing the fun stuff.
Wednesday, August 16, 2006
I'm not sure if this will help. It's what I've experienced.

What you have described is something which happens in many projects I've been in. The best way I feel is when one of my leads agreed that it is a boring part and that he knew it was so. He requested us to bear with it so that we can get it out the door and get into another exciting one as early as we can. That acknowledgement was very sensible.

In contrast, another lead in another project gave motivational talks the way he did during the project initial stages. It sounded sillier at the end than it did in the beginning. Initially it is okay as the work is in itself interesting. If something is done deliberately to speed up certain parts of a projects it's usually obvious to people and they don't take it seriously.

The acknowledgement that you understand what they feel comes first. Taking people out or giving incentives, etc can be done in addition to this.
Senthilnathan N.S. Send private email
Wednesday, August 16, 2006
+5 for what Kyralessa said.
Lux Send private email
Wednesday, August 16, 2006
Read this book: http://www.amazon.com/gp/product/0974036919/103-9086982-8395029?v=glance&n=283155

I'm almost done reading it, but I already changed the way I see the behavior of my team.  I think he's right almost all the way.  He makes a comparison with tribal behavior and explains how it reflects within a company.  Really good book I think.

Anyone else read that book?
Hugo Send private email
Thursday, August 17, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz