Setting Deadlines in software development [duplicate]

Question

I have been working on a system alone for about two years. I inherited the system from a contractor who spent about two years working on it before me (alone). The system is not particularly well designed because there is business logic, presentation logic and data logic mingled together. It is a very complex system, which I am trying to refactor as I go along and this takes time.

A new developer was recruited but he seems to be taking more of a Project management role. He is very direct asking exactly how long things will take; questioning all my assumptions and predictions, which is difficult because of the complexity and because I am the only expert at the moment.

I am very organised in my personal life. For example, I was asked what time I would arrive in Manchester last week so I provided an exact time catering for accidents and road works on the way. I find it difficult to apply the same principles at work in software development at the moment.

Don't get me wrong. I have worked with project managers on less complex projects in the past and have had a good relationship, but then the projects were less complex and I always delivered before schedule. I am struggling with this particular project manager and it is causing stress.

How do other developers deal with project managers who want answers and accurate deadline dates?

Answer 1

What's the new developer's role? Is he working alongside you, are you mentoring him, is he senior, is he the solution owner or manager? It seems like he wants to get a grasp of the solution and understand where the complexities lie.

A new developer was recruited but he seems to be taking more of a Project management role. He is very direct asking exactly how long things will take; questioning all my assumptions and predictions, which is difficult because of the complexity and because I am the only expert at the moment.

It's normal for a new team member to ask questions. How else would you expect someone to get up to speed with the solution - the issues, the design designs made, and so on.

Your question raises more questions for me. What are you answering? If he says 'How long with x take', and you respond 'I don't know' or 'We won't know till we start', or similar, I'd be very concerned. You've been working on the solution for two years and you have a responsibility to give guidance on the project. You are, after all, the expert.

Answer 2

Ask for the target level of confidence to be used in estimates. There will be a big difference between 50% and 90% confidence.

Answer 3

I believe fully an agile approach to software development will always fundamentally give a more satisfying and valuable experience for both sides.

For me this means three things. 1. Sharing a vision for the product (Un-timebound understanding of what 'this thing is'. For example "The best ever salon management tool for hairdressers") 2. Defining current shared goals. (time-ideal real 'things' that make up the vision. For example "Within 6 months we will be able to handle bookings and stock") 3. Deciding what to do next. (estimated tasks for the next iteration. For example "this week I will have a list of all currently available software tools for salons". Or "this iteration we will complete user authentication").

Your iterations should be SHORT (my current preference is a week) and should result in releasable 'things' or experiments that give concrete learnings. It is then the 'clients' decision if what they have is enough. This is a key point: they have something.

Any plan is out of date as soon as it is written. It is a promise waiting to be broken. It is inflexible to change - change is a fact of life. Planning is essential, but a plan is useless. A PM (if one is ever needed - IMO it is a task not a role) can then line up the estimates and goals regularly and 'see where they are'.

Be lean, be agile. Build measure learn and trade in 'done' not 'promises and apologies'.