Does programmer scheduling software exist?

Question

We are a three man programming team with a huge scheduling problem. We need some software to help us manage this problem. We could build this software ourselves but we would rather use somebody else’s brilliant solution.

Does anyone out there know of one???

Here’s the problem. Let’s start with a clean slate.

A programmer in the company is given a new job to do. Say its 5 days work. We tell the client its 8 days work as we will be interrupted and know the real production time is going to be longer than 5 days.

1 day into the job the programmer is interrupted with a critical bug that needs to be fixed on another project. The ideal system would allow us to insert this task into his schedule. It would then warn us that this task is conflicting with the original task and ask us to set a priority. We would prioritize the bug over the job and all would be well as the original job still has 2 days slack. The programmer would know the bug is more critical. And the system would tell us that the original job can still get done.

Then perhaps another more critical task would interrupt that bug. And other tasks would appear. Eventually, the slack in the original project would be lost and the system would need to indicate that projects or bugs won’t get done on time.

Multiply these tasks across three programmers and multiple jobs and it is pretty easy to reach complete uncertainty about the delivery of anything!

That’s the problem we face.

Standard project management software like Microsoft Project does not solve these problems. It requires the manual insertion of tasks and the manual creation of dependencies. We have tried to use it and found 1 -2 hours a day wasted in scheduling without any real clarity about what was going on. I eventually decided that was because project managing and task scheduling are fundamentally different.

I have a pretty clear picture of the software I have in mind.

Surely it exists? Please, someone out there

HELP !!!!!!!!!

Answer 1

Previous questions here that might help you.

http://stackoverflow.com/questions/161590/how-do-you-track-your-time

http://stackoverflow.com/questions/108066/whats-the-best-way-to-track-and-submit-a-timesheet

http://stackoverflow.com/questions/37139/how-do-you-maintain-a-project-schedule

Answer 2

You could adopt SCRUM. Build a backlog of work, work in sprints and then you can appropriately estimate the time needed for tasks which will help with future scheduling.

Are you using any kind of issue tracking system that can also keep track of time?

Some good options for basic project management would be Basecamp or if you do decide to adopt SCRUM then you should check out Mingle (which does a KILLER job managing agile projects!).

You definitely need to address how you're handling bugs and how you handle developer interruptions. I'm not too sure if any scheduling software is going to help you out with that.

Answer 3

It's not a scheduling issue you have, it's a management issue. The initial bug which pushed the client back was fine, as you scheduled for such a disruption. The second task though should have been either assigned to someone else, or pushed behind the client task, as you no longer had time for slippage.

And the developer needs to be in a position to know this, and state that additional tasks will make delivery for the client late.

It would then be the manager's task to either push the client (and get the chance to tell the client they've been pushed) or set the other task as less priority as the client's task.

Answer 4

For a 3 person team, if you are all in the same place, I would recommend a whiteboard or using 3x5 cards for tasks and sticking them on a wall. This has much less overhead than software solution. For large teams, distributed teams or where you need to export reports for management then software solutions are maybe necessary.

Using something like SCRUM and then continually updating a burndown chart as tasks complete will show you your progress towards the deadline. Also, if all the tasks are visible on the board you can easily see which tasks are remaining.

We used to use paper charts on the wall then switched to X-Planner and now ScrumWorks. I still think the paper charts worked much better but our team is split across two sites and management wanted to track progress, so we changed to use a tool.

Here are some links to give a better idea

• http://www.infoq.com/articles/agile-kanban-boards
• http://www.informativeworkspace.org/walls.php

Answer 5

I agree with Stephen and David.

You might even get some mileage out of a lowly Excel spreadsheet. Each developer could have a spreadsheet for his or her interrupt tasks, and it could do the arithmetic for calculating completion dates based on priority. If they're kept in a shared folder and updated regularly, management can keep track of who is working on what and where the potential slips might be.

Answer 6

Yeah, it is a very real concern. I would be sceptical of anyone who said they had a software that could fix all scheduling wows. Its not a matter of technology, its just the reality of business is unpredictable.

The prince2 manual has it that a staff member should only be marked as able to do 3.5 days of productive work in a week (i.e. out of 5 days).

I have seen people try and fix this problem. GS (a company i worked for) was the most advanced on their approach. They did two things. For starters, it was the MD that organised the programmers time, he would go in and change around their outlook calendar. So when a programmer came in, they would look at their calendar and see what they were meant to be working on from that. You would have to put in a ‘resource request’ if you wanted a programmers time on something (just a short email with about 5 lines). did this work, not really.

The thing which GS did do which was impressive is this; they had a position called ‘maintenance programmer’. It was this programmers job to do bug fixes and small changes on legacy projects. This is powerful, because now you arent pulling programmers off work to do bug fixes.

You can actually schedule programmer time quite nicely using joels spolskys scheduling style, its pulling them off work that is the killer. and i saw this done a lot at a company i worked for, the programmers constantly got pulled off to do other stuff, and because of that my schedules were for-shit.

i developed a good way to alleviate this though, a system called ‘primary/secondary programmer’ (this system was nixed by my boss by the way). It worked like this: you have two programmers on a project, one is the primary and he has 20 hours work allocated, the other is the secondary, he has 10 hours allocated. If 5 hours of new work comes up, it gets given to the secondary – he is now lagging 5 hours behind the primary, but he can still complete his work before the primary does (the project isnt finished until the primary is done).

Bug tracking software is also a massive help.

One of the other commentators in that article also said it, its not a scheduling issue, its a project management issue. Its the project manager that must decide priority, not the programmer, and not the boss. This is where i have seen real trouble, when the boss assigns priority. The project manager needs to allocate time for bug fixes in smooth spots through-out the week and at appropriate break points.

LM

Answer 7

As everyone else here, I doubt that for a team of three developers any specialised scheduling software is needed, apart from an issue tracker and a spreadsheet. Even if use of an automated scheduler was made, it wouldn't help. For the reason that all scheduling software known to humanity so far has one essential flaw in respect to your problem: none of it is capable of actually making time, it just shuffles things around.

The remedy for your problem is likely to include:

• Understanding the difference between work required to complete a task (in time equivalent) and duration of a task. Work means how much time spent purely on the task is needed for successful completion. The duration is the actual time period within which task can be completed given specific context (amount of actual hours that are going to be contributed each day, lead times for dependent tasks that are not included into the work estimate i.e. waiting for information etc). When a developer estimates something at 5 days and then further 3 days of contingency is added it is really important to specify whether the estimate is given as work or duration. Estimating duration is an extra step. In your case, when the same developer deals with business support on part time basis it has to be reflected in duration. It sounds as if though your work estimate was 8 days you should have set duration to at least 16 days, this was the earliest it could have been delivered given that you're not likely to have developer working on it full time (more likely ca 50%).

• It makes sense to schedule time and resource for bug fixes and post-implementation change requests in advance. Assume you have the deadline for delivery of the feature to be in 16 days, assuming that the feature is going to take 8 days work. Schedule at least half a day worth of post-implementation support to be done some time in three weeks time. You're going to need it.

• To simplify scheduling and time tracking you could assign one of your team to do most of the business support whilst others work on projects and features uninterrupted. Obviously the work could be done by each one of you on rotating basis.

Answer 8

I have found Mingle to be a massive help for our small team

Pros

• It supports scrum or XP
• It's extremely flexible
• It's free, or it used to be free (for teams of 5 or less)

Cons

• It can be painfully slow at times (newish Mac mini with 2GB), but is awesome on quad-core with 8GB
• Can be a bit hard to grasp at first

You can find it here

• http://studios.thoughtworks.com/mingle-agile-project-management/

Disclosure

• I have no association with ThoughtWorks other than using their s/ware

Answer 9

You might want to have a look at the Project management and "Evidence-Based Scheduling" in Fogbugz.

Answer 10

Take a look at ibm's jazz (http://www-01.ibm.com/software/rational/jazz/).

Answer 11

Try http://www.yutiti.com . It is really simple, effective and free of charge. It did help me :)

Answer 12

The fact of the matter is, Project Management takes time. You have to allocate that time as part of your time scheduling, which means pushing out your tasks. 2 hours a day, for all 3 developers does not seem out of line to me.

Your problem is that you want Project Management for free. It's just not possible. Tools can't automatically make the kinds of decisions you need to make in project management.

You've got two choices. 1) keep padding your estimates to hopefully make up for the issues you face, or 2) allocate time to project management using existing tools.

Answer 13

Oh I see! If only you could get all the peculiarities of the requirements of everyone's schedule, rates of pay, value to customer, probabilities of what could go wrong and with what severity etc... into a centralized database then a computer could solve the problem, or maybe put enough of a dent in it that an enlightened manager could improve team performance.

This is the old central planning vs. free markets problem except in a programming shop and with more modernized tools.

Friedrich Von Hayek had this to say about the failure of central planning ["The Use of Knowledge in Society, AER, 1945]. I wholeheartedly recommend reading the whole thing, but the key point can be distilled from the first two paragraphs:

The reason for this [that central planning of a society fails] is that the "data" from which the economic calculus starts are never for the whole society "given" to a single mind which could work out the implications and can never be so given.

The peculiar character of the problem of a rational economic order is determined precisely by the fact that the knowledge of the circumstances of which we must make use never exists in concentrated or integrated form but solely as the dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess.

In developer speak, people often won't or can't communicate all the knowledge needed to draw up schedules. The knowledge can also be contradictory (A thinks the bug is fixed; but B disagrees; C says he is still working on the main project but D thinks he finished yesterday and is goofing off). Because of this, scheduling and productivity is undermined by both unforeseen events and people's manipulation of the system to their individual advantages.

The 'free market' approach is also not trivial to implement. Most workplaces are far too dictatorial. Multitasking often is forced on those least capable and the costs of a reassignment of effort are often never calculated or even if calculated not paid by the person with the power to make the reassignment. The first thing you need for a free market system to improve performance is for property rights to exist. If you are an owner/partner then you could tell your developers that they own their time so long as it is used for the company, and are free to work on what they want, but put a system of known rewards and penalties in place. But then that speaks more to culture than programming, I suppose.

If the three of you are a partnership, or each independent contractors, then this is much easier than in a big company. What is important is probably not how many projects you finish but the combined long term profitability of the effort. When someone says 'bug X should interrupt job Y' and person 1 needs bug X fixed, and only person 2 who currently has job Y knows how to fix it, then maybe there should be some money that changes hands between 1 and 2, or something, to offset the loss of productivity on job Y. Person 2 should be figuring the cost, and Person 1 should be figuring whether that is worth it to them to pay or not. If not, then the bug can wait.