Task Database

See TrackingTool, NoBugDatabase.

Having a TaskDatabase is not only good as a TrackingTool, also serves the purpose of GivingAcceptableEstimates?. See GiveMeEstimatesNow for a related AntiPattern that can be avoided using a TaskDatabase.

A TaskDatabase is also useful for you to GetToKnowYourPeoplesSkills. Some developers finish earlier than they estimated, others estimate too long and even then, they miss the deadline.

In my opinion, RapidEstimates are a must to keep the ProjectUnderControl?. No developer should continue his coding unless he has estimated all his pending tasks. You would find this awful, especially if I forbid any estimate to be longer than 3 days. See EstimatesLongerThanThreeDaysConsideredHarmful.

Developer: No problem. I will divide the task in several smaller tasks. All the tasks that can't be done by me, will be assigned to other groups, with no estimate from me and not including their tasks in my estimate. I will even divide my tasks so that I can estimate the smaller ones and then assign a big huge estimate to the one that will take the most time.

Manager: Mhhh, everything seems fine, except this big huge task here that takes more than 3 days. In total, if I remove that task, everything is ok, I will then reassign this task to the developer that is the strongest in this area, (probably me), he will divide this task and assign the remainings to this developer who was collapsed by this task.

The same developer as above, eventually receives the same task he overestimated, but now the pieces are smaller. The estimates for most of them will be small and possibly one of those task will again be too much. The manager repeates the process until all tasks individually take less than 3 days or a number of days agreed before the project started.

-- GuillermoSchwarz

Insecticida supports subdivision of tasks, tracking of estimated vs. actual time, etc. See http://sourceforge.net/projects/insecticida/ It is based on Workbench (another SourceForge project), it uses PHP + MySql. I have not released any files, but the source is in CVS.

The todo list assumes that you centrally control all the information on your laptop and no one has access to it. Information is not public and therefore developers can't make predictions and think in advance. Also it becomes harder to communicate technological risk, because everything is so unpredictable: they said it would take 1 week, but oh wait, what if the foomangler has integration problems with the barmingler? It could take 2 weeks to fix that, so are you supposed to schedule a meeting to communicate that risk, even if it doesn't materialize? Usually managers are busier than you are, so it is always a bad idea to interrupt, especially if the interruption looks later like a waste of time.

So the solution is to make it as impersonal as possible: write all tasks down in a task database. Anyone can read, add or change anything on the TaskDatabase, but everything is logged and you can't delete anything, so developers are careful and even more important: managers are even more careful. If they change their mind and that has a big impact, it is recorded, so they tend to change things slowly and developers feel like they are productive.

This is important because a demoralized developer will not write good code, even if he tries hard. A tired developer will not either. A tired and demoralized developer will destroy whatever was working even if he tries hard not to. The TaskDatabase solves all this because the developer can show how his effort was detroyed by external forces. He can rest and tomorrow he will fix whatever that needs fixing. Sleeping well is important to work things right. UnitTests also help a lot in this area. -- GuillermoSchwarz

Who writes the task database originally?

The best systems are always the simplest. Someone who comes up with a complex system demonstrates that they've not done their homework or they're not qualified.

My experience with programming so far is that you need a good architect and a good programmer, a good relationship between the two and a good to do list updated constantly.

-- GuillermoSchwarz

View edit of July 28, 2005 or FindPage with title or text search