some thoughts on providing software development estimates.

Well most probably, some of you are responsible of providing development (effort) estimates (in man hours) for your project. You are either the senior developer of the project or the software architect or some sort of project manager. You need to provide an estimate anyway anyhow.

Ok let's agree that strictly this process of providing estimates is not very aligned with the developments of a methodology like Scrum, where you have some sort of monthly time boxing and the estimate of effort is limited within this time box BUT (that is the difference) it might change the significance of features in your backlog list. Anyway let's get to the usual old process since lots of shops out there work that way!

1.I can hardly remember (actually 1 or 2 cases) in the various projects I have worked for- architects or team leaders that really master 100% the complexity of an enterprise application.Meaning that, through time large applications are getting more complex and complex meaning that people involved in specific parts of this application as the time goes by are transforming themselves into something I call - micro experts. Micro experts are usually developers but the more time they spend on specific areas the more seem to grasp it's complexity.

That leads me to the following idea, when you are about to provide an estimate for a specific part of the application you should always evaluate the expertise of your partner developer. In most cases it is a bit cruel to ask someone - please tell me how much you need to fix that - because it adds more pressure to him/her. Pressure is something that destroys the moral of software developers when it is applied to issues that they think it's not their business (that is really understood). The proper way would be to have a small chat with him, let him explain the problems, apply your own expertise as well (if you are senior enough as assumed) and then work out a realistic plan. The more senior he/she is the better estimate he would work out.

So, eventually the advice is, always try to talk to your partners or let them express their feelings-ideas. Do not either leave them with no choice by dictating estimates or leave it 100% up to them. I have to admit I have gone through this bad decision and the final results were disappointed.

2. Plan for the worst, aim for the best. Strictly meaning that if you and your team can not provide approximate estimates and you end up in some sort of min-max days, I would suggest you end up by giving the max days. The more complex the project is, the less experienced are the developers with the specific code base or internals - the safer is to choose the max estimate. Eventually that does not mean that the max days should be spent 100% if the developer manages to overcome problems and progresses smoothly then you will have some spare days in your plan - to be spent on testing or on another feature!

3. Always evaluate the experience and the skills of each individual developer.Some managers always assume that they have a team of equally skilled developers. At the same time, in case of a big application where the fragmentation in the area of expertise is larger - Developer Y is very good on the front end, developer X is very good at the back end where developer Z is very good on the business complexities of a specific module - YOU CAN'T shuffle them or assume they can instantly produce code on areas they have not touched before. There are other similar cases like - developers that have just arrived to the project and it's experience in the code base is limited. In case of emergency they are not very helpful comparing to the more experienced members. In other words, do not expect everyone to be as productive in areas that he/she has not touched before, especially when the time frame is very strict. In case team members have to mess up with parts that are not their area of expertise always increase your estimates and have a some sort of risk plan. We assume that a professional developer would always try to provide a solution but we must not treat software developers like code producing robots - each one of them has a special set of skills and needs time to adjust himself/herslef to a new development context.