4

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?

5
  • 13
    If a developer is expecting an exact answer for "when this is going to be done" - he's not a developer. Time estimate is an estimate. Also, if he's in developer role - why is he trying to manage?
    – Evgeni
    Sep 7, 2013 at 18:09
  • 3
    If someone asks me for a task and I don't know exactly how long it will take, I will tell him exactly this. If he starts questioning my estimations or assumptions, I tell him he can try do solve the task by himself if he thinks he can do faster.
    – Doc Brown
    Sep 7, 2013 at 18:26
  • How can you make work-planning more like trip-planning? And the answer is to come up with repeatable known tasks. You and the other developer can do the estimating process together before you assign the work to one of you.
    – dcaswell
    Sep 7, 2013 at 18:41
  • what's the question?
    – Reactgular
    Sep 7, 2013 at 20:32
  • 1
    @Mathew Foscarini,"How do other developers deal with project managers who want answers and acccurate deadline dates?" as quoted in the OP.
    – w0051977
    Sep 7, 2013 at 21:27

3 Answers 3

5

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.

2

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

2
  • This answer is short but sweet. The fundamental estimation paradigm for a software project should recognize that the total cost and schedule for software development is unknowable to high precision in the early stages of a project. Sep 8, 2013 at 13:48
  • books.google.com/… Sep 8, 2013 at 13:51
1

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'.

2
  • The problem with this approach is it prohibits the business and finance leaders from making good decisions about contracts and projects. The margin of profit for doing a job is based on how long it will take. Without knowing this, it impossible to decide whether to take on new work. Sep 8, 2013 at 13:46
  • I don't agree. But this is not the right forum for a discussion about a truly agile approach with buy in from all sides and a fight between agility and a desire for false comfort through wasted time spent planning/documenting a future that will change. :D
    – CodeBeard
    Sep 8, 2013 at 14:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.