Hot answers tagged scheduling
117
But my current company insists on my being there at 8:30. Any deviation from this is a big deal. Is this typical?
Yes it is typical. And companies like that tend to have very high turnover with developers. I was chatting with one of the project managers I used to work with (he's now a VP with some other company) and he was describing the policy at the ...
44
I'm stealing this answer from somewhere on SO. I can't seem to find the original author but the answer stuck with me.
Pointy Haired Manager: how long will this take?
Employee: hard to say, a month? maybe a month and a half?
PHM: We need a better estimate
E: Look, how long does it take you to drive to work?
PHM: Huh? 30 minutes why?
E: 30 minutes plus ...
36
Software estimation isn't actually more difficult than estimating other types of work. It just seems so because the CONDITIONS under which it's estimated are more difficult. Say a software company was tasked with something similar to what a car company is tasked with. Build the same thing over and over again, which has existed for decades, and with only ...
22
Software development isn't a manufacturing type process where people are essentially interchangeable resources. It’s a creative process that works within the collaborate environment of a professional team that takes into account individual abilities and skills. It’s not making widgets, packing boxes or flipping burgers. In fact, these kinds of throwing more ...
16
Joel Spolsky wrote an article on Evidence Based Scheduling that may help you find some arguments.
You have to convince your co-workers that better estimation skills can help them produce better software. Here are some points in favor of tracking task time:
If you have an arbitrary management-set deadline, good estimations will tell you what you can ...
15
it's because the last 20% of the project usually take 80% of the time. The initial outline is probably because people often base the total time based on the core mechanics, without realizing the finer details of the project. It's less of a programming question and more of a psychological question in my opinion. You ask a person how a helicopter or a lock ...
14
One of the (reasonably legitimate) reasons I haven't seen mentioned yet is that in many/most companies, support issues get escalated to the developers who know their product. To avoid critical production support issues going unanswered, the company expects the developers to be at their desk for the full client business day.
In a past company I worked at, it ...
13
You really need to talk to your boss about this and set some ground rules:
A deadline is not a deadline unless you commit to it.
An estimate is not an estimate unless you give it, and then it is an "estimate" not a hard deadline.
Robert Martin's Clean Coder has a really good chapter about how to communicate this stuff to your boss. It is not your fault ...
10
A while back I worked for a major investment management company. Most people connected to their core business got there no later than 6:00am. Most devs came in no later than 8:00. But I liked to come in at 10:00. (I still got up early, but I like to exercise for a couple hours first. lol.) My boss? He couldn't have cared less. All he cared about was results. ...
10
Have you guys been in similar situations? What has/hasn't worked for you?
Mostly what works is speaking truth to power.
Gather the facts. Present the facts. Leave the customer to learn (or not learn) at their own pace.
My team is blamed, feels discouraged and there's an overall atmosphere of defeat.
Why is your team aware of the blame? If the ...
10
The measure of how good scheduler is would be average/total wait.
Assume you have a set of jobs J, within these you have job x which is the longest. Let y be any other job.
If you put x last, total wait time of the jobs executed before will be total(J)-time(x), while for any other it'll be total(J)-time(y). Thus only putting the longest job last minimizes ...
9
It's normal, but it shouldn't be. I am a major advocate of the fact that we as developers should not be treated the same way as other office staff, because the nature of our work is vastly different and is not quantifiable by being at your desk for 8 hours. In fact from my experience, being forced to be at your desk 8 hours a day fosters the desire to ...
8
You can accomplish this in the standard way - carrots and sticks.
The carrot(s) in this case could be "improved future estimation by understanding our current velocity" - but you would have to follow through.
Your comment that they are not often involved in project scheduling may make this a tough sell.
The most high-functioning among them, particularly ...
7
I disagree that an Agile project has no upfront plan.
My experience is that the business analysts have spent a fair amount of time working in design meetings with customers and developers to come up with a detailed list of achievable requirements that are presented as user stories. These are then broken down into tasks with suitable estimates attached by ...
7
Because you have potentially infinite variables to estimate against and you have users that don't really know what they want (or can't accurately express what they want).
"Design a car for me". You design a car, but they really meant a truck. Well, it DOES have wheels, right...
When we estimate we try to get the first estimate within 25% and the second ...
7
Joel Spolsky says that a software development team is a scheme for converting capital (money) into working software. Honestly, from your question, it sounds like your team is good at that: you're getting decent software for reasonable amounts of money invested.
Now, of course the next step is to put the software into service. Until your company chooses to ...
6
Good way
Use software, which actually makes that easy and almost transparent, like for example Mylyn. Combine it with tools like for example an hour burn-down chart.
Bad way
Force them to fill in tedious timesheets, where you have to manually specify project, task, exact dates and times etc.
6
In my experience, the following are the problems with most time tracking software:
The developer does not have the ability or authority to break down a task into more easily estimatable subtasks on the fly.
There is no good way to account for subtasks you didn't know about until you started working on something, a situation which comes up all the time in ...
6
Run, do not walk, to get Software Estimation: Demystifying the Black Art by Steve McConnell. The first few chapters are full of answers to the exact question that you are asking.
If you come away with nothing else, come away with an appreciation of Tom DeMarco's observation that in most organizations the definition of an estimate is, the most optimistic ...
6
Every company I have ever worked for has core hours. Some are more liberal, some are more strict, but the intent is that employees are more productive if they can consult their coworkers about problems.
If one developer likes to be in at 5:30am and out at 2pm, and another is in from 10:30 to 7:30 and takes an hour lunch, then there isn't much time to ...
6
Scrum leans towards eliminating slack
Yes and No.
Scrum forces you to make an intelligent "time for innovation and other good things".
"Other good things" are what retrospectives and daily stand ups are for.
"innovation" is what technology spikes or spike solutions are for.
They don't go away. They aren't buried.
They become first-class, ...
5
Building a bridge isn't so precise. In fact, I would bet they usually run over budget as well. I know a planned tunnel b/w NJ and NY just recently got canceled b/c of overruns. And think of all the (American) football stadiums built recently that all go over original estimates. Just grab some of those examples, and drive home that building things we can ...
5
The problem is that customers don't know what they want. They only have a vague idea.
However to find out, you must start building a software, which you will then change.
What you would want software development to be like is Analysis > Design > Implementation.
This is what for example construction works like. Nobody would dare to say 'ok, just start ...
5
"late" in an agile methodology means the same thing it means in a waterfall methodology: the estimates were wrong, the scope was too big for the allotted time, unexpected difficulties appeared, the customer wasn't responsive enough, the programmers got lazy, the machines crashed, your dog ate my bytecode, etc.
you learn from it and adjust for the next ...
5
It's not unreasonable.
Even though it might not be ideal to your needs as a person or a developer, it might make sense for everyone else. Having everyone come in on time helps identify who comes in late. Having everyone come in on time helps minimize arguments regarding "why does he get to come in late and I don't?". Having everyone come in on time helps ...
5
Well I guess that is a programming question. I think it is pretty common.
As to why...
It might be that they feel collaboration will work better as it is a problem when different time zones and schedules are involved.
Along the same vein, this might promote a better "team" atmosphere.
And of course it's always possible that you're superiors are forced ...
5
I've been in this exact situation and it wasn't pleasant. However, one approach I did was to meticulously keep a record of work that is currently in development. When tasks come along, you remind the client, management or project manager that other work is going to slip as this has now become their priority (sometimes that can make them second guess and ...
5
What should I do when my project manager does not care about implementation details?
The project manager (PM) should not care about implementation details. That's not their job, but rather the job of the software developers. Ultimately, the responsibilities of a project manager are to control the cost, schedule, scope, and quality of a project. ...
5
Having Development and QA on separate shifts that are mostly opposed works out pretty well in my experience. Say the Dev team is in the US and the QA team is in Romania.
This gives you a few hours of overlap in the morning EST for syncing up without overly burdening either side to be up extremely early or work extremely late.
This also lets you ...
5
First, watch this video:
http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain
Executive Summary:
The way you ship on time and on budget is this: when you run out of
time or run out of money, you ship. That's it.
The reason most
projects don't ship on time is because someone comes along with "just
one more feature or ...
Only top voted, non community-wiki answers of a minimum length are eligible
