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 project manager enters the first issues, which are probably customer requirements. But anyone should be allowed to enter new stuff. Just triage them, that is, spend 30 minutes each day classifying new issues and prioritizing issues. Priority is very important: not only should project managers agree with them, but developers should also agree with them. Also the remaining work should not exceed the available time to finish it. Each module has a team (even one person is a team) and of course each issue is assigned to a team. Inside the team, the team leader assigns issues at will so that nobody is idle. The TaskDatabase must record when people were idle because that's something you don't want to happen.
Nothing can be deleted, you can only add information and change the state of each task. Everything is logged and everything can be seen by everyone as DirectManipulation suggests. OpenCommunication? is a very important feature.
[When something is written there is no way to escape it] - I think that's one interesting property of having everything written down and readily available, but it is also something people fight against. If I've never used something like Insecticida before I will be afraid that it will show how poorly I did something. The same occurs with PairProgramming: developers are afraid that others will realize that they don't understand exceptions, resource leaks or threads, so they reject PairProgramming per se, without saying anything convincing. I think of this the following way: have a good reason to do it and then have a good excuse to do it in public.

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.

I agree, but you need to be an expert to realize what is simple and what has unnecessary complexity built-in. Usually experts agree on the basic stuff, but they never agree on the advanced stuff. So if you ask an expert: Is this basic or is this advanced? They should always say ***basic***, but that would go against their own best interest: Experts can't charge big bucks for something that is basic.

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.

I think in XP the programmers are all architects and all architects are programmers. I agree that all architects must know how to program, but I doubt all developers can be good architects, mostly because they think they are so smart that they can solve anything, so they come up with all this complicated stuff that they didn't think thoroughly. The TaskDatabase avoids all complicated stuff, because you can never estimate a task longer than 3 days: Your manager will take that task from you, so you tend to come up with simple solutions that must work, or the task will be assigned to someone else anyway. A requirement for this to work is that you never hire only rookies: you also need experts in the room, and by saying that, I don't mean developers who have worked at failing projects but developers who have shipped products.
I've tried PairProgramming very long ago and it works wonderfully. If two programmers can do something independently in 3 days, the pair can do it in 1 day. But it is hard to convince people to pair. But observe when people are stuck, they usually ask for help and they pair naturally, unfortunately they feel ashamed to have done so.

-- GuillermoSchwarz