Fog Creek Software
Discussion Board

What do you tell them?

Here's a quote of another thread:

> I've had some very frustrating moments as a manager
> where guys have spent entire weekends coding things
> like custom date-entry controls on projects that already
> had some schedule slip. What do you tell a guy who
> enthusiatically spends heaps of his own free time on
> something you view not only as useless but actually
> detrimental to a project?

Yes, indeed, what do YOU tell them?

Here Th. ere (e-Very Where)
Sunday, June 1, 2003

How about:

thank you for looking past the crushing incompetance of management, and taking your precious time to come in on a weekend

Daniel Shchyokin
Sunday, June 1, 2003

You try to get them on the same page as you as quickly as possible.

If you're the manager, then it's your responsibility to ensure they understand the end goal, and the current state, any obvious obstacles they may encounter, and so on. Once everyone knows where you need to go, when, and what problems you face, I think you'll find that people will tend to start organizing themselves.

Sure you'll get a guy who's overly obsessed with figuring out which minivan to rent from time to time, but most of the time I think you'll find that everyone else chips in and does what needs to be done to get to your destination on time.

And for the guy who is still focusing on the wrong thing, then you just need to communicate even stronger the need to take into account the whole picture when he works rather than focusing in on one thing.

Considerations in Communicating Intent

1. The purpose of the task (the higher level goals).
2. The objective of the task (an image of the desired outcome).
3. The sequence of steps in the plan.
4. The rationale for the plan.
5. The key decisions that may have to be made.
6. Antigoals (unwanted outcomes).
7. Constraints and other considerations.

(Klien 1994)

My own version is that you need to communicate:

1. The desired outcome
2. The current state
3. How you plan on getting there
4. Any considerations
5. The why for any of the above

(Wieczorek 2003)

Commanders Intent Statement

Here's what I think we face.
Here's what I think we should do.
Here's why.
Here's what we should keep our eye on.
Now, talk to me.

(Weick 1983)
Sunday, June 1, 2003

If it is the programmer's own free time, I don't see why you should care about.

I understand  that if the programmer has failed to follow the schedule it's his responsability to do whatever he can to meet the deadline. If he does't finish his work on time, there is no relevance on the fact that he spent the weekend programming useless stuff, he might've spent it at the movies and it would not have been any different. It's up to him to decide how to spend his free time.

The problem is when he really thinks that he worked overtime and that he was getting work done. But I supose that if something like that happens, it is because the developer does not have detailed enough functional specification and project plan, and I would have to admit that it is my fault, as the manager, if my team members are working hard on irrelevant things.

The only difference between spending the weekend doing core functionality or spending the same weekenf doing some nice-to-have cool but useless stuff, is the lack of communication between the manager and his team.

So, I would have a meeting with all team members to assert what the top priorities are.

That is, supposing that the team cares about what the manager thinks. Otherways, you are in the hole.

Sunday, June 1, 2003

Speaking from personal experience, it's quite likely that someone might enthusiastically embrace these side tasks and not the main project because they're genuinely interested in the side tasks and don't particularly care about the main project. 

Here are some reasons why they might care more about the side task than the main project:
* They don't like their job.
* They don't respect their manager.
* They don't feel that they've been compensated fairly for hard work on past projects.
* "Coded custom date-entry controls" looks better on a resume than "Went down with a sinking ship". 

Something that's not clear is if the custom controls work was done completely on personal time.  If so, I don't see what the gripe is, assuming the programmer is pulling their weight during normal work hours.  If not, isn't it the job of the manager to direct the work of those they are managing?  Hence the term 'manager'? 

Sunday, June 1, 2003

Stupid situation.
Tell them that they are not getting paid for the useless work they just did.

Give them $50 to buy a calender control that does a 1000 times better job than the hack they put together on the weekend.

Sunday, June 1, 2003

What an extraordinary post!

Management has stuffed up the scheduling so much that the developers need to work in their own time.

Further, the developers seem to understand something the manager doesn't; that dates are tricky, vary in interpretation between countries and systems and are a common source of bugs. Accordingly, the developers are saving the manager's bacon by getting it right.

And, no, third party controls are often not a solution.

To the original manager, what you could say is: "Thanks."

Must be a manager
Sunday, June 1, 2003

The part I don't understand about the original quote was about his work being detrimental.  I mean, maybe if it's not tested or not solid code, but then if that's a problem, then you're going to have the same issues with whatever he writes. 

Just interesting that extra work on a late project is deemed detrimental - even if it is for something that's not core.  From my experience with projects, it's amazing what winds up being core when you finally get all of the users in front of the app (as oppsed to the "Core group" that management puts together to approve specs/prototypes.  These end up being the guys that the users want to get out of their hair so they can get real work done more often than not.)

Unfocused Focused
Sunday, June 1, 2003

If the project is being run correctly, then code outside spec is always detrimental, because there's more to it than just code - now the custom calendar control has to be tested, debugged, and documented. Based on McConnell's recommendations, the developer has spent 16 hours of his own time and cost you 16 hours of project time.

Things to tell him (in private):
1) Thank you for the work you've done. We do not have time to add it to the current project, but we'll keep it in source code control and look at it for a future release.
2) I hope you understand we cannot compensate you for the time you spent working on this, since it does not contribute towards your assigned tasks.
3) In the future, if you would like to work overtime, please talk to me in advance so we can ensure you are working on appropriately prioritized tasking.

I'm sure to some of you this sounds like managementspeak, but when you have a deadline, all development needs to be coordinated and managed; having a bunch of cowboy coders doing what they like doesn't help anyone.

BTW, who said the project was late because it was mismanaged? Maybe it was late because all the coders keep working on what they want to do instead of what they are assigned.


Sunday, June 1, 2003

I agree with Philo.

Generally if something is important to the project the programmer should let the manager know and if it is needed it will be added to the project or scheduled for a later release.

What a programmer does on his own time is his business but when he presents it to the manager as something to include in the project it can become a distraction to the project.

The manager now needs to decide whether it works, what affect it has on other components, what impact it has on documentation, how implementing it will affect the schedule, what impact not using it will have on the programmer's morale, what impact using it will have on other programmers (why are we changing working code to implement Charlie's silly control). Since the manager may not be able to do all of this himself he will have to pull in other project members to review the component. He will also have to explain to the users why the application has a new look when all they want is the project done.

Lets change the example a bit:

A user who knows the project schedule is behind requests a new date control like the one he just saw in a presentation. There is no business reason for the change but he would like it, but he cannot extend the due date or pay more for it. And he has not talked to the other users about this change. Assume the control is free so the development cost is nill do you want to make this change?

John McQuilling
Sunday, June 1, 2003

"If the project is being run correctly, then code outside spec is always detrimental, because there's more to it than just code - now the custom calendar control has to be tested, debugged, and documented."

Exactly.  There is a time in every project that all code checkins to the release branch must be made against a specific issue or bug.  Some would argue that this policy should be in place through the entire lifespan of the project.  I would not argue with them.

Regardless, you need to set policy:
1. What gets checked into release code.
2. Release code is the #1 priority.
3. Each check in _must_ have a corresponding feature request or bug id assigned to it.
4. You must feature freeze the release code - no new features get added.
5. You must provide the encouragement to push through to project completion, and communicate the importance of completion.

If you do not declare a feature freeze on release code, then you sabotage your own declared importance to project completion.  After all, if you or project mgmt, or marketing can keep adding features, why can't the developer?  Release discipline starts with good management and communcation.  If you don't exhibit it, no one else will.

You need to have a complete bug list, which is updated continuously and be informed regarding progress against the bug set.  I could ramble on, but that's enough.

Nat Ersoz
Monday, June 2, 2003

He's working on the date control because that's what he wants to work on. He thinks it's important enough that it's what he wants to do first.

Who gave him that idea? or failed to give him a better one?

The management has noone to blame but themselves.

You tell him this...  "I resign"

Trust me.. he'll probably love you for it!

Kent Design4Effect
Monday, June 2, 2003

Kent, interesting analysis, and I won't argue with it in general, however...

This may come as a shock to you, but there are in fact individuals, even in our learned discipline, who don't follow directions. Are you really going to blame management in toto for every single malcontent or misguided act that happens on their watch? Not even the military does that.

In addition, this could be a case of "first encounter" leadership - what manager ever thought to tell his/her employees "and oh, by the way, if you're gonna work on this on your own time, please stick with the plan"? Until someone does it, you probably wouldn't think of the possibility or the ramifications.

There's also the issue of not being able to actually direct the activities of your employees when they're off the clock. I can't order you not to code improvements to a project over the weekend... But when you bring those improvements in I can tell you "thank you very much, but we can't add those to the project right now" - which is what the original post asked. :-)


Monday, June 2, 2003

Some places make you sign a non-disclosure agreement before programming.

Theres almost always a clause saying all code generated within becomes the property of us and the only coding permitted on the premises is as specified by us.

What if the manager drafted such an agreement, pased it out to all the programming staff and adopted it as policy? One person wouldn't have to be singled out and management could say  it's a policy change to increase productivity.

Option #2
You say "Look Newton, it don't matter how long you fart around with the damn date control, it ain't gonna help the fact that we're running 3 weeks late!"

Kent Design4Effect
Monday, June 2, 2003

That kind of behaviour can be detected as one of the signs of a project out of control, however, it can also be a way of blowing off steam of even taking time out to let a problem sort itself out in the background conscious.

There is no single response that's adequate because it depends a lot on the who it is that's doing it and the relationships involved.

Frequently within a team there is a maverick, they'll push against the boundaries all the time, they'll question and argue, often passionately and sometimes they might not have the same commercial goal in mind as everyone else.  Sometimes, if it becomes too outré it also becomes detrimental and they're behaviour has to either be managed or removed.

And sometimes they produce nuggets of gold.

I've had a few experiences where in the midst of clearing alligators someone has wandered up and said 'oh well I have a whole new swamp we could put in I was working on at home' or whatever and its been one of those critical changes.

So, the answer is, as it so often is in untidy real life, it depends.

Simon Lucy
Monday, June 2, 2003

"BTW, who said the project was late because it was mismanaged? Maybe it was late because all the coders keep working on what they want to do instead of what they are assigned."

Philo, as far as I am concerned, this in itself is a sign of a mismanaged project or company.

Where you cannot coordinate the work of the coders, and get them to produce the right code, then you have failed on the mgmt side.

Monday, June 2, 2003

tapiwa, if you cannot coordinate the work of the coders, during their off hours,  you have failed on the mgmt side?

It must be a great prison system you like to run under.  As if Project Managers and Technical leads do not have enough to do, they now must control the free time of developers?

Yeah, right.  That will work.

Monday, June 2, 2003

There seems to be a way to finesse this.  Having code in the repository doesn't mean the build tools need to use it.  Thank the nice coder who codes in their spare time for being such a resource.  Make sure the code is modular so it can be kept from the build and don't make a big deal out of it.  We will likely have similar software engineering measures, about knowing what to include in each build, so it shouldn't hurt the coder at all.

Monday, June 2, 2003

I've done this exact thing. I once spent a weekend (my own time) writing a date control. It allowed us to remove at least a hundred lines of complex date validation code that was always buggy. We've used it in every project ever since - it takes just 6 lines of code to re-use. We now have dates in a standard format so everyone knows exactly how to handle them.

Why did I do it? I was working flat-out on a project with an impossible deadline. At all times it was a case of "do the fastest thing possible, no matter how crappy, to get things working/finished". There was no chance of improving my skills or learning new things or thinking of a better way to do things - no chance to innovate or be creative.

So I decided to spend the weekend being creative and coding something simply because I found it interesting.

I think that you should say nothing at all to this person. It's their time and they can spend it however they like. They'll probably take the skills they learnt while writing the date control and save you some hours somewhere on your late project.

Monday, June 2, 2003

If you do talk to him at all, make it obvious you appreciate him doing...well, anything on his own time. In short, if you try to handle it at all other than "thanks and we'll keep it in source control, even if we can't use it right yet", you have to handle it carefully, or you can simply get the pay-off of having them not  do anything for work on their own time.

So long as he isn't in the dark as to the use or uselessness of what he did (assuming it wasn't something good)  - in which case you might want to address it, if you are rationally confident in your ability to handle such things - just don't bother at all. So long as it doesn't hurt his paid time work, you haven't lost anything but the few spare kb to store the stuff somewhere and be grateful for the sentiment.

Monday, June 2, 2003

Back when I was a naive youngster I remember making this same mistake, and being well managed.

My manager said very nice, all we need is some of the supporting paperwork and then we can use it.

I was then given a list of all the necessary supporting paperwork that would be needed.

Never did get round to completing all that paperwork :)

Ged Byrne
Monday, June 2, 2003

InDenial. I hate getting into personal attacks, but if you would only read my post, you would realize the flaw in your attack on me, and my "prison system".

You write:: "tapiwa, if you cannot coordinate the work of the coders, during their off hours,  you have failed on the mgmt side? It must be a great prison system you like to run under. "

If you read Philo's post (and the bit I quoted), he suggested the the project might be late not due to mismanagemet, but because of the tendency of developers "to work on what the want ... instead of what they are assigned."

here is my logic.
1. I am assuming that the work assigned is assigned during work hours. If this work is not done, then mgmt have failed.

2. I would also argue that if mgmt is assigning coders work outside their work time, then again, that is a sign of failure on the part of mngmt.

Not once did I suggest that mgmt should control the developers free time.

Monday, June 2, 2003

"Maybe it was late because all the coders keep working on what they want to do instead of what they are assigned"
That's a management failure right there. If the management don't keep track of what is going on and realise that slippage is being caused by people doing wtf they feel like then its a management problem.

Monday, June 2, 2003

As most people have said, your programmer needs to be gently kept on the same track as the rest of the team. Thank them for their efforts, but point out that they could have been much more helpful if they had spent the time on something the project actually needed.

However some programmers I've met (not most) use working in their own time as a kind of political weapon. They want things done their way, and think that if they present you with a finished piece of code (or more usually a half finished piece of code) that does it their way you will be forced or persuaded to use it.

The easiest way to tell if this is the case is the response to the gentle correction suggested above. If they say 'sorry I didn't realise' then they were just trying to be helpful. If they insist that what they did was the right thing to do, and theirs is still the best approach, and especially if they imply you are an idiot for not seeing it, then you have a situation like this.

The trouble with these situations is that if people see the weapon works then they will use it all the time. If you think you have a case like this, put the code aside where you can get it should you need it in the future, and get back to the original plan.

David Clayworth
Monday, June 2, 2003

I think a very important point being missed here is the intention of the programmer.  No where in the post does it state that:
1.  The programmer wanted to be compensated for his overtime.
2.  The programmer wanted the feature in the initial release. 

My thoughts...I think the OP misinterpreted the programmers comments.  What if the programmer just did something he thought was *cool* and wanted to show it off.  Maybe the OP doesn't realize that programmers are a different breed.  We code because we want to.  Maybe the programmer just broke up with his girlfriend/boyfriend and just wanted to code :)  Just a thought.

Monday, June 2, 2003

It sounds like this programmer actually cares about the product.

With management like that, he'll soon get over it.

Monday, June 2, 2003

David - Sure I can believe some programmers would do that. The important thing is they're not thinking of it "as a weapon" they just figure you can slide it right in since they did all the work.
Tuesday, June 3, 2003

Gotta love it!

These coding scoundrals need to do what they are told when they are told and how they are told! No independent thinking or initiative will be tolerated! Those who do not submit to the authority of the whip will be dismissed!!

Oh yeah.. that's how they do it at all successful IP companies... Not!!

So Philo, does this slave driving high handed authoritartion system work well for you in producing crap of the finest caliber? Now I see what the problem with Camel was - an idiot at the helm!

Ghengis Khan
Tuesday, June 3, 2003

Ghengis Khan.
Can you read? No seriously, can you read?

No one is arguing for a slave driver approach to managing. having said that, though, mgmt is about coordinating efforts, to achieve a common goal.

If that means saying "no, you can't write the latest xyz. we need the documentation first!", then so be it. Now if you think this is slave driving, then good luck to your projects.

The bigger question on how you compensate, or deal with work that developers have, out of their own voilition, created outside their normal work hours, remains.

Do you compensate? Do you acknowledge? Do you give time off in lieu? Do you keep for next release cycle? Do you just say no thanks to it all? Presumably something like this would not have been in the original spec.

I think the way to deal with it is to find out why it was done.

1. Did the programmer do it as a mental challenge? Good for her. You have a keen one. Nurture their interest. Coach them. Assign them more challenging work.

2. Was it an ego/respect thing? Reward it yes. However, emphasis should be made on the fact that this can never be allowed to affect their assigned work.

3. Was it a politics thing? Be afraid. If the only way to get ideas considered in the organisation is to do it first, then there really are serious issues.

4. Was it a .....

Tuesday, June 3, 2003


I agree that the 'I'll just slide this in and nobody will notice' approach is more common (and still needs to be dealt with by the manager). In this case the programmer wanted to challenge the manager's decision in order to undermine their authority. You could tell because they made a big thing about it, instead of keeping quiet and hoping nobody will notice.

Guys, guys. It's not a case of dictatorial manager versus total freedom for programmers. Assuming that a programmer has been given a chance to state their case for doing it their way, if the team leader still disagrees then the programmer should buckle down and do it the way they've been asked to. Managers (or team leaders) have a job to do, and it's making decisions like this.

David Clayworth
Tuesday, June 3, 2003

*  Recent Topics

*  Fog Creek Home