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

131–140 of 152 posts

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

#131

Post by jsprogrammer »

abduhl wrote: post #127
jrs235 wrote: post #126

Earlier quoted context omitted.

Software development is very different from building physical structures. "How much is it going to cost to build my house?" "Give me the blueprints and tell me your finishes." [Waits on client to provide specs...]

What's the difference? "How much is it going to cost to build this application?" "Give me your specifications for the app." [Waits on client to provide specs...]

I'd guess the usage of [Waits on client to provide specs...] in the software scenario is a bit facetious.

Often clients can't produce specs sufficient to build an application. Some clients may produce 'specs' which are incomprehensible, making them impossible to estimate.

The crude part is, that such projects may still go on, and worse, the client may believe that the application is actually being built to the specs.

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

#132

Post by st3v3r »

jsprogrammer wrote: post #72
eterm wrote: post #21

Earlier quoted context omitted.

A fixed cost makes it easier to turn and around not pay (in whole or part) if the product is really not up to the standard specified. It's harder to do that if the cost is not fixed but overrunning and the response is "well we just need more time". Also fwiw, the team wasn't selected on price.

Not pay? Heh. For work performed? OK... That is why my contracts require payment up front.

To be fair, they're talking about subpar, unacceptable work.

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

#133

Post by chillacy »

mikeskim wrote: post #96

You could just use data, machine learning and optimal control to make better estimates. It has aleady worked for fighter jets, self driving cars, and automated factories. With enough data it will work for anything.

What kind of features would we use? Which prior projects will help predict how long it takes a team of 3 developers (one of them senior with a history of underestimating time, two junior with little track history) to produce a novel photo sharing app where the requirements might or might not change every day?

The problem I see is that there isn't enough data, and the problem space (the number of possible projects and teams) is too large to draw meaningfully on past data.

Unless we're looking to predict specific CRUD apps where the requirements are known up front and a team cranks these out consistently.

Humans have already been flying fighter jets, driving cars, and doing work in factories, so we know it's a learnable skill. We have not yet learned how to estimate arbitrary software production.

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

#134

Post by ddingus »

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…

That is the worst conversation. You have to admit you can't do it, and you have to force them to evaluate what is worth what.

Of course, part of that evaluation is you. Almost unavoidable.

They have to admit you are not an infinite resource and that they are asking for more than is realistic.

The very worst is by the time this all happens, they have most likely already pre agreed to just get it done, or they themselves were told to just do it.

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

#135

Post by aidos »

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

Earlier quoted context omitted.

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 co…

You've been given a lot of good advice on here - I concur with all of it. After almost 20 years of writing code I still couldn't tell you how long it would take to debug something in my own codebase. If I can visualise it, sure, I can take a guess, but if not, who knows what I'm going to find.

Given the questions you've asked on here, it really sounds like you were just in a bad environment. You said 3 hours, it took a week - you're a junior, why the hell didn't someone jump in to help out?

Everything you've asked comes down to experience and you need people around to support you in gaining that experience.

Good luck finding a nicer workplace - honestly, sounds like you have the makings of a good inquisitive developer mind. There are plenty of places out there that will help you develop your full potential.

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

#136

Post by ddingus »

davidgrenier wrote: post #47

> These are the skills that elevate someone from a good programmer to a great software engineer I stopped reading at engineer

You really shouldn't.

While the term engineer is loaded with the licensing and professional aspects, and understandably so, the people working with software very often do actually have to perform the task of engineering solutions.

Dismissing a valid dialog on this basis does no one any real good.

Despite the issue you raise, the query and discussion remain valid and high value.

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

#137

Post by sombremesa »

pestaa wrote: post #98
Ensorceled wrote: post #12

Earlier quoted context omitted.

It leads to what I call "do it right syndrome". Since I have time, I'll do it right, with a factory class, and extendible configuration package (that I'll write myself so it will be just perfect) and, for optimal speed, I'll use Red-Black trees that I'll have to write my own implementation of since there isn't a standard library ...

What's wrong with separation of concerns, extendability, optimal speed, etc.? More often than not, I observed doing it right the first time is actually a huge time saver compared to hacking some stupid prototype nobody can understand later.

Agreed, except in cases where the code will never be maintained again (e.g. game releases on N64). In my experience an "over-estimate" that leads to the so called "do it right" syndrome happens if someone else estimates for a developer. When the developer makes the estimate him/herself and doubles it, you can be damn sure they are going to need all that time and then some to even get it in the ballpark of long-term acceptable.

(That being said, the company needs to have standards for code acceptability in the first place, which doesn't always happen)

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

#138

Post by abduhl »

jsprogrammer wrote: post #131
abduhl wrote: post #127

Earlier quoted context omitted.

What's the difference? "How much is it going to cost to build this application?" "Give me your specifications for the app." [Waits on client to provide specs...]

I'd guess the usage of [Waits on client to provide specs...] in the software scenario is a bit facetious. Often clients can't produce specs sufficient to build an application. Some clients may produce 'specs' which are incomprehensible, making them impossible to estimate. The crude part is, that such projects may still go on, and worse, the client may believe that the application is actually being built to the specs.

Often clients can't produce specs sufficient to build a house/building/pipeline. That's why there is an entire category of firms that exist that are hired by clients to produce these documents.

Guy wants an apartment building, he hires an AE firm and tells them "I want an apartment building" and they say "well what kind of apartment building?" and then goes through the exact same process of defining scope, budget, and schedule that would be done in any other project management field. Lawyers get hired when someone wants to sue someone - "well what do you want to sue them for?" Sourcing managers get hired when someone wants to make something - "well what do we need to buy?"

The fact that the software engineering industry refuses to acknowledge that their industry is not special is a constant source of confusion for anybody who has been doing this in another industry. Why is the software industry special? What makes software so nebulous that scopes cannot be defined and estimates made? The argument that "people don't understand the impact of requests" does not hold water - people don't understand that simply wanting more room in a particular part of their house can cause an entire redesign. That's why you, as the expert, have to explain the impact of their requests clearly rather than just agree to them.

The problem with estimates and scheduling in software engineering isn't a result of work, it is a result of failure by the project management.

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

#139

Post by sombremesa »

bigmanwalter wrote: post #86
jahaja wrote: post #61

Earlier quoted context omitted.

So if I understand you correctly you're saying that "creative software development" is inherently incompatible with the hierarchical realities of the corporation? If so, I think you're probably right. "The reality of this trade [..] is that everything is required for yesterday" But it just isn't. This is an artificially created pressure for selfish reasons, and should not just be accepted in passing.

The game is rigged. Only way to win is not to play.

Or according to the parents of this reply, to play under the wing of an expert player.

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

#140

Post by jsprogrammer »

paulddraper wrote: post #124
jsprogrammer wrote: post #68

Earlier quoted context omitted.

Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver? Good developers should ideally only ever do the same thing once, which means that there is very limited utility in trying to improve estimates for a task that you should never perform again.

In general, this is a terrible practice. "How much is it going to cost to build my house?" "Er, I'd rather not commit to a price. We'll figure it out later."

That is not the only alternative.

"$300/hr + expenses; hours and expenses determined by necessity to complete work; work as described represents at least 100 hours effort and $x in expenses"

Post reply on HN