Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What do you mean ‘we need more time’? Project schedule estimation in software

blogs.dropbox.com

Post reply on HN
Print view View original

101–110 of 152 posts

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#101

Post by work-on-828 »

fenier wrote: post #56
work-on-828 wrote: post #50

As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do…

It comes down to experience really. The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates. If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements. Sometimes you need to do research to give an estimate. If someone asks you in person, o…

> comes down to experience.

Yea. I really should get into the habit of keeping better records of things so that I can look back on past projects. I write in a paper notebook as I program, but that is usually just thinking out loud or trying to artificially increase my working memory.

> If you don't have a spec, get a spec.

Yea, I think I've concluded that I need to always write a spec for myself before I start a project. I know Joel says that PMs should write specs, but I should be prepared for the reality that projects rarely have separate PMs.

The hard part is how to write out the technical details ahead of time before I've gotten my mind into the codebase Im adding onto or the new framework I'm using.

> Risk assessments

Any tips on what to read to do these effectively?

> Once you understand what is going on

So I should feel safe in disregarding the advice to "avoid trying to understand the universe"? Or at least attribute it more to how I communicate about being stuck on a problem? That is kinda a relief. I really didn't understand how to put that advice into practice.

> A few good books on estimation and debugging

I've read Debugging: 9 Indespensible Rules, Mythical Man-Month, Critical Chain, and a few chapters from Software Estimation: Demystifying the Black Art. Do you have any other recommendations? The latter three books seem to be talking on the level of projects that are anticipated to take at least 6 months. I'm looking to start out with being able to reliably estimate how long I can get done in 90 minutes.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#102

Post by Gratsby »

orky56 wrote: post #81
Gratsby wrote: post #79

I'm about to being a rant here because this is a larger problem than anybody likes to admit. Developers are good at development. By and large, they are not good at task management, project management, and certainly not estimation. One of the primary reasons for this is that their plates are always overflowing and they work more efficiently than many people in other professions. They shift priorities on the fly when w…

Ideally a product manager solves or assists with many of those problems- 1. Reduce the ambiguity of what features to work on and what are the priorities. This involves being the barrier from other manager and team members trying to pull a fast on and changing what should be worked on. 2. Stay on top of what the latest estimates are in an honest and transparent way. Product managers as project managers should be able…

Theoretically yes, and if you're the unicorn, then I'm sure you are very appreciated (and probably under-compensated). Seriously. I'm not mocking you.

With a person who's job is to help you and who is not above you on the food chain, you are more likely to have an honest self assessment. Also, with a third party in place, fairness becomes part of the equation. When a developer has to defend his timeline it's personal and can be very stressful. When a third party has to defend the same timeline it's just a matter of business. Conversely, when a third party is in play that is told that a developer needs to produce more, their instinct is to prioritize accordingly rather than simply add more hours to the work day (which is a common instinct among developers).

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#103

Post by work-on-828 »

DougWebb wrote: post #90
work-on-828 wrote: post #50

As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do…

For a lot of these, rather than trying to estimate the thing you're asked to estimate, you need to either estimate how long it'll take you to do the analysis you need in order to come up with an estimate, or you need to provide a time-limit on the task after which you'll provide a status update and have a discussion about the next step. Managers don't really care about time, they care about budgets and risks. In your…

It sounds like you are saying that when I take an hour to work on debugging something, I should spend 55 minutes taking notes on the system and where the problem might be and 5 minutes turning those notes into a coherent email. Is that a reasonable approach?

I certainly prefer to think of debugging as a process of learning about a system rather that trying to try things at random without making a mental map of where I am.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#104

Post by [deleted] »

DougWebb wrote: post #90
work-on-828 wrote: post #50

As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do…

For a lot of these, rather than trying to estimate the thing you're asked to estimate, you need to either estimate how long it'll take you to do the analysis you need in order to come up with an estimate, or you need to provide a time-limit on the task after which you'll provide a status update and have a discussion about the next step. Managers don't really care about time, they care about budgets and risks. In your…

[deleted]

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#105

Post by Gratsby »

squeaky-clean wrote: post #93
Gratsby wrote: post #79

I'm about to being a rant here because this is a larger problem than anybody likes to admit. Developers are good at development. By and large, they are not good at task management, project management, and certainly not estimation. One of the primary reasons for this is that their plates are always overflowing and they work more efficiently than many people in other professions. They shift priorities on the fly when w…

Going to join you in this rant if you don't mind. > Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. Ugh! For real! I had this happen to me recently. I have trouble t…

I feel your pain.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#106

Post by work-on-828 »

pdpi wrote: post #88
work-on-828 wrote: post #50

As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do…

As a general rule, if management expects results without giving you the tools for the job, ask yourself whether you really want to be in that job, and start looking for alternatives. That said, there's several ways you can make things better: > What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan…

> As a general rule, if management expects results without giving you the tools for the job, ask yourself whether you really want to be in that job, and start looking for alternatives.

Well the hard part here is determining if lack the tools due to management disorganization or due to my own lack of skill or intelligence. I have already left the organization.

> you _can_ estimate things correctly once you have the context

Maybe my problem comes down to not recognising when I lack a piece of context or being stubborn enough to get it.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#107

Post by Jemmeh »

anon4 wrote: post #11

> The fact that I technically only asked how long the fix would take is something only an engineer would bother pointing out. -_- Well excuse me for not fitting your prejudiced profile for a neurotypical extroverted 20-something white male. Yes, I might have needed the clarification between "how long will it take you to paint the room" vs "how long until the room is back the way it was with the walls in a different c…

If I am talking to my PM I will say, "It will take me an hour to fix that. But I'm working on project XYZ right now so it will be sometime next week. If you need me to do this first though, just let me know."

Because to me part of being a PM is deciding project priority.

In room painting analogy, "Painting the bedroom will take about 2 days of work. But I am working on the kitchen cabinets which will take at least 2 more weeks. Do you want me to stop that to work on the bedroom so you can move in your bedroom furniture first?"

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#108

Post by bcbrown »

work-on-828 wrote: post #50

As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do…

> What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature?

What I would suggest is that you should learn the practices of wherever you are working, and not spend much effort trying to change them. Your first couple of jobs, you'll hopefully be exposed to several different methodologies, and only then will you have the experience to advocate for best practices, as well as being able then to speak to evidence of it working at a past job.

> What do you do if asked to estimate how long something will take to debug? What if you just started on a project and the error message you are trying to debug doesn't make sense?

If you can't accurately estimate debugging, instead explain what you understand, what you don't understand, what you've learned so far, and what you're planning on trying next.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#109

Post by lliamander »

eterm wrote: post #17
soft_dev_person wrote: post #9

Earlier quoted context omitted.

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

Absolutely this, clients need to know their costs upfront. Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost. That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs... As a customer it wasn't…

I'm curious, did your contractors host regular demos, sprint retrospectives, etc.? If so, was it clear early on that the results were going to be substandard, or was it a surprise fairly late into the process?

I'm not going to debate about whether they were doing "true Agile", but it seems like even without settling upfront costs it would still be possible to control risks by tracking value added vs. cost on a sprint-to-sprint basis. Hopefully it should be evident early on if the project isn't worth it[1].

Of course, this requires that the contractors be able to deliver value incrementally, which might not be possible in all projects. In which case, upfront cost estimates (and more thorough planning) will probably be necessary.

[1]In fact, this is exactly why Zed Shaw says he uses Scrum on risky projects(http://zedshaw.com/archive/the-c2i2-hypothesis/)

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#110

Post by bcbrown »

work-on-828 wrote: post #101
fenier wrote: post #56

Earlier quoted context omitted.

It comes down to experience really. The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates. If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements. Sometimes you need to do research to give an estimate. If someone asks you in person, o…

> comes down to experience. Yea. I really should get into the habit of keeping better records of things so that I can look back on past projects. I write in a paper notebook as I program, but that is usually just thinking out loud or trying to artificially increase my working memory. > If you don't have a spec, get a spec. Yea, I think I've concluded that I need to always write a spec for myself before I start a proj…

> Do you have any other recommendations?

You might take a look at www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005/. Although it's 20 years old, it has some good ideas in it. It's also more about 6-month estimations than 90-minute estimations, though.

Post reply on HN