Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I came across this link Parkinson Law where it says like "Work expands so as to fill the time available for its completion."

Do you agree with this? If yes, how do you enforce this with the people? In our case, if we ask the people to complete the task sooner and ask them to leave, some people they feel it as demotivate. What is your opinion to avoid the demotivate feel as well as complete & leave from work soon?

share|improve this question

closed as primarily opinion-based by durron597, enderland, Ixrec, Snowman, MichaelT Sep 2 '15 at 0:15

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

In theory I do not like working more than 40 hrs per week, but sometimes the only way to make something right is to put in overtime. – Job Dec 10 '10 at 15:09

10 Answers 10

up vote 27 down vote accepted

As a programmer, all I want is a deadline. "Has to be finished by Friday, 13th". That's all I want, that's all I need to know. I don't like it when somebody tells me how many hours to spend, or when. If I have a great day, when code pours out like water from a waterfall, I want to be able to work late. If not, I want to be able to leave early.

share|improve this answer
+1; and I'd add that bosses who tend to micromanage additionaly scew things by insisting on managing every piece of a programmer's work. – Jas Dec 10 '10 at 13:22
This is why all firms who hire programmers should give them flex time, and the more flexible the flex time, the better. – justkt Dec 10 '10 at 14:39

On working late:

I'm a fan of the XP approach - that people should work 40 hours a week. I think 40 hours of focused work combined with time for other interests, friends and sleep is more productive than 60 - 70 hours and nothing else. There are occasional instances where we ask for weekend work and the like but it's two or three times a year.

That said, programmers are adults and I let them manage their own time (so long as they're doing their minimum contracted hours). I've politely suggested to people that they really don't need to be working late when I'm getting mails at 11pm and there's no big deadline but generally it's up to them.

On Parkinson's Law:

This is oft quoted but I'm not sure too many people have really looked at it's origins and whether it's really applicable. The phenomenon was primarily observed was the British civil service in 1958 and then in government organisations since then and related to environments where empire building and a lack of urgency were common place.

Personally I'm not sure that that will really tell us too much about the workings of modern IT functions where there tends to be a drive for efficiency and continual pressure and deadlines which combat much of what it describes.

It's probably more true in very large companies to an extent, where the necessary bureaucracy can take hold, but I don't think the motivations it talks about (essentially empire building) are things that programmers are driven by and therefore it's impact at the level where work is actually done should be minimal. Of course projects may become mired at the analysis and management levels where those factors are applicable but that's a different thing.

So I don't really buy it for most IT organisations as it's originally formulated.

I think there are problems which lead to something which looks like Parkinson's law (essentially people are given tasks which are too large, don't apply themselves at the beginning thinking they have plenty of time and then have to work like crazy at the end right up to the last minute unnecessarily), but that largely comes down to poor management (by the PM who should have set interim deadlines) and time management (by the programmer who should have buckled down at the start).

Edit: At Pierre's prompting this summary from what Peopleware says about Parkinson's Law from

Newton's Laws have stood the test of some 200 years of subsequent study. Parkinson was a humorist, not a scientist. His "law" caught on because it was funny, not because it was axiomatic. His examples were observed in a fictitious British government bureaucracy, where they give little job-derived satisfaction. The simple truth is:

Parkinson's Law almost certainly doesn't apply to your people.

Their lives are too short for loafing on the job, as that would delay the satisfaction they hanker for. They are as eager as managers to get the job done, provided they don't have to compromise their standard of quality.

"You Wouldn't Be Saying This If You'd Ever Met Our Herb" - In a healthy work environment, the reasons that some people don't perform are lack of competence, lack fo confidence, and lack of affiliation with others on the project and the project goals. They are overwhelmed by the diffculty of the work, pressure won't help, reassignment, possibly to another company might. Treating your people as Parkinsonian workers certainly won't work, it can only demean and demotivate them."

share|improve this answer
there is a chapter on Parkinson Law in the book Peopleware I know you like a lot ;) – user2567 Dec 10 '10 at 12:56
@Pierre - I'll have to reread. My copy is at home rather than on my desk... – Jon Hopkins Dec 10 '10 at 13:07
@Pierre - Found a summary on the net and edited to reflect. – Jon Hopkins Dec 10 '10 at 13:13
so you get my upvote ;) – user2567 Dec 10 '10 at 13:14

The real solution is to make sure that your deadlines are sensible in the first place.

The setting of deadlines should be the result of a conversation between the customer (when they want the functionality) and the developer (when they think it can be delivered by). Your role as a manager/sales person is to guide that conversation and get both sides to agree to a compromise.

If you get it right then you won't need to ask your developers to work late to get the job finished. Very occasionally you might get to release your product early because you underestimated - but that's really just a chance to get the next items on the list done!

There will be times when people either feel the need or have to work late to meet a deadline, but these should be few and far between.

However, we don't live in an ideal world so these times are more often than we would like.

share|improve this answer
Go home early? The only time I've heard that was followed by "and don't come back!" Over the cubicle wall, of course, and not directed to me... :) – Wonko the Sane Dec 10 '10 at 15:35
@Wonko - perhaps a bad choice of words ;) – ChrisF Dec 10 '10 at 15:36
@Wonko: I had a manager that often told me to go home, not accompanied by "and don't come back". Admittedly, he may have only said that when I'd slept on the office couch the night before... That whole period is kind of fuzzy. – Nicholas Knight Dec 10 '10 at 16:33

At my current employer, deadlines are pulled out of the air without discussing them with the people who will be performing the tasks. Consequently, working late is frequently the only way to even attempt to meet the deadlines.

disclaimer: this week, I gave notice that I'm quitting.

share|improve this answer
Did you make sure to reference… when you gave notice? :) Good luck in your next endeavor. – Wonko the Sane Dec 10 '10 at 15:37
@Wonko, well, I wrote the resignation letter just like I described in that thread. – Tangurena Dec 10 '10 at 17:24

Let people estimate the tasks (preferably in a group, so that they can come up with a consensus). This will allow you to set a reasonable deadline. Then leave them alone...

share|improve this answer

This depends on your company policy I guess.

Some companies have scheduled minimum hours to be put in each day, so they would be expanding work to fill their day.

Why would someone feel demotivated if asked to leave early - hey I would love days like those. Dont they have families or homes to go to?

share|improve this answer

I had a co-worker discuss how the introduction to a 5pm Friday code-freeze meant that half of all bugs and 80% of all commits that broke builds were made from noon to five pm Friday.

I have no idea if late hours work for your group or not.

I would suggest you check your VCS commit logs and see how often are bugs introduced after 5pm. 7pm? 10pm? Compare that to how often bugs are introduced from 10am to 4pm.

Check your CI server. Are commits that broke the build usually near the deadlines?

Next, check how often deadlines are missed due to bugs that were introduced by people trying to get something in before the deadline.

Your problems might be bigger than just not enough time.

share|improve this answer

On one side, good software needs a lot of communication between those who make it. So you want everybody to be available to communicate with for as long as possible each day.
On the other side programmers are programming best when they are left alone, so you need to leave them room to be alone whenever they feel like it. Often, evenings are a good time to be left alone, but will make people turn in late and/or tired the next morning.

A good manager is one who balances these two so that their team is most productive.

share|improve this answer

If I allow them to come in late, I allow them to work late. I prefer the former more than the latter, however.

share|improve this answer

I work for a start-up company and have a vested interest in the company doing well in the form of stock options. As such, I'm willing to put in extra time, although no one is "on my back" or anything like that about putting in significant extra time. Albeit, part of their decision in hiring me in the first place is that they knew I was the type of person who would be okay with putting in extra hours in the first place, which is a mentality that all the developers here share.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.