Skip to main content

Why big tasks are hard to estimate properly and what to do about this.

I will begin this by stating clearly: you should never get to the point where you need estimate how long it will take a big task to be completed. You should never have big tasks in the first place. There are a lot of reasons why having big tasks is a seriously bad idea.

Firstly, big tasks have big requirements and by the time the developer is halfway there he will most likely have forgotten parts of the requirements. A developer working on a big task needs to keep the requirement fresh inside his mind each day. Otherwise if he forgets some things he won't implement them at all. This is an issue even where I work. So extra time is wasted just refreshing those requirements.

Secondly, big tasks tend to affect a lot of systems inside an application. Most developers don't know all the systems in the application so he might spend a lot of time figuring out how those systems work and how does his task affect those systems. A series of smaller tasks can be worked on in parallel and you get more flexibility when assigning developers to those tasks. You can choose for example developers that are experienced working on areas and systems related to those tasks. On bigger tasks it's almost impossible to find a developer that knows all the affected areas. Having more developers with better understanding of the implications of the changes will reduce the development time and number of bugs.

Thirdly, it takes a longer time for a big task to reach the testing period. A small task reaches the testing period faster which means that the testers will never run out of work.

And finally, smaller tasks are easy to fix because you have a smaller portion of code that you need to analyze for bugs.

No wait, there's more. Smaller task are easier to accurately estimate. Even if some of them takes more to finish, you can keep a ratio of 50/50 of tasks that are finished earlier and tasks that are finished later. If you keep that ratio and sum up all the time it took to complete them you will have a better change of being on track because everything will balance out.

All in all, I think that the extra time wasted to split a big task into smaller tasks is recovered later due to the things I mentioned above.
Labels:

Comments

Post a Comment

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things...
3 comments
Read more

Protected variations in software engineering explained and extended beyond the common usages

While digging through some standard programming principles like low coupling and high cohesion I stumbled upon the fact that they are part of a larger series of principles called "GRASP" principles. After reading a bit about them, they seem just as important if not more important than the "SOLID" principles And one particular principle from that series stuck with me: protected variations. According to this principle, variations and changes in parts of the application should be contained only in them and not trigger further changes in the application. In general terms points of inflection should be established between the parts that change and the rest of the application which act like a boundary and stop additional changes from propagating to the rest of the application. For example, one of the most common parts that might change in an application, is the data access and storage methods. For example instead of using direct sql to read and write to a database, an...
1 comment
Read more

Some things which are often blindly applied and followed by developers which are not always good

This is probably one of the most controversial things that I have written so far but I am just tired of hearing about these things and discussing these things. Other developers that I know share part of my feelings. I would rather hear more about how people built things, overcame challenges or what new interesting ideas and concepts they implemented. Those things are really interesting and innovative, not hearing about the same theoretical things over and over again. I can just read and learn those things from 100 sources on the internet. Firstly, one of the most discussed and promoted things is agile/scrum development. I think I have been through 5-8 workshops about agile development methodology. And each time, some things differed. There is no 100% standard approach to this. Everyone uses their own version of this development methodology and seem to argue a lot that their approach is right and everyone else is doing it wrong. You go to an interview, this will be one of the first 10 t...
1 comment
Read more