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

All late projects are the same (2011) [pdf]

systemsguild.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: All late projects are the same (2011) [pdf]

#41

Post by kgilpin »

jayd16 wrote: post #20

This is why "agile" methodologies caught on. Ignoring how they're used as internal political cudgels now, the most general goal of agile is to constantly adjust scope and estimates. This way, we can accept that we're all terrible at estimates but we do our best not to paint ourselves into corners because of our terrible terrible estimates.

He doesn’t think estimation is the problem. He says that the projects are started late and that developers are handed a deadline by the business and then accused of being late when they can’t meet that deadline.

Re: All late projects are the same (2011) [pdf]

#42

Post by kgilpin »

rossdavidh wrote: post #2

While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.

I think you’re missing the point of the article. His original theses was that we aren’t good enough at estimation. And in fact much hand wringing over estimation has been done in this industry over the last 6+ decades.

Now he’s amending his opinion to state that estimation is not really the core issue. The core issue is that projects are doomed from the start by mismanagement. Issues such as: racing to catch up with a competitor (giving the s/w group an impossible deadline), or starting a project whose business value is so low that minor time and cost overruns reduce the actual value to below zero (at which point people start blame shifting to try and hold on to their jobs).

Re: All late projects are the same (2011) [pdf]

#43

Post by jcadam »

shoo wrote: post #36

One perspective is that negotiation of schedule and resources is often nothing resembling estimation but is a political game. Ed Yourdon's book "Death March" has a chapter about Negotiation . http://ptgmedia.pearsoncmg.com/images/013143635X/samplechapt... There's a list of "negotiation games" that, sadly, you'll probably recognise. And a bit of more practical advice: >> The problem I have with “estimate” is that I un…

Bah, your estimate is meaningless anyway, since someone five levels above you in the org chart has already promised the customer that feature X would be available in 3 weeks. And that promise was made last Tuesday, so by the time it gets to you, there are only two weeks remaining until the deadline.

You'll know this is the case when you say "at least a month", and the PM looks at you like you just shot his dog.

"The answer I need is two weeks."

Re: All late projects are the same (2011) [pdf]

#44

Post by marvin »

mden wrote: post #7
rossdavidh wrote: post #2

While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.

and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…

I had this experience recently. We don't use a lot of detailed estimates in my team, because the work needs to be done regardless, and the estimates are then largely a waste of time.

But there was one occasion, where a product launch had been announced by a C*O before the product was finished, and the engineers were very clear that this launch date was impossible. So there was a lot of drama and bad feelings, and the engineering team eventually said, "okay, let's make a detailed estimate so we can be certain". The estimate came in at three weeks development time, one week after the announced launch date.

One week of the estimate was meant for testing and fixing problems that are found in testing. The business experts immediately jumped on this: "Testing and fixing unplanned errors won't be a big deal and certainly not a whole week. We'll skip that so we can get it done in two weeks".

Thankfully, this is retail banking, so releasing an obviously broken product flies even less than missing the deadline. The product was eventually launched uneventfully, one week after the detailed estimate and two weeks after the announced launch date. All in all a success.

Re: All late projects are the same (2011) [pdf]

#45

Post by Gravityloss »

collyw wrote: post #40
avip wrote: post #23

Earlier quoted context omitted.

Salesperson to raging customer (aftermath): "We were only able to complete the bathroom in the estimated time. You are welcome to live in it for a reduced monthly fee while we build the rest of the house around you"

In my experience new build houses and apartments are never on time either.

there was just a recently completed apartment building here which was months ahead of schedule. They tried more agile methods when doing it: daily meetings instead of weekly ones and working more in parallel. It was done by a less dinosaury company called Fira.

Re: All late projects are the same (2011) [pdf]

#46

Post by sgt »

Sharlin wrote: post #33
trainingaccount wrote: post #22

Earlier quoted context omitted.

We sure don't want it to go over time and budget like the last 10 projects.

Just need to manage the lazy developers better (read: more) this time!

More meetings will do the trick. A daily 30 minute standup, and a few alignment meetings scattered throughout the day to identify the technical causes as to why progress is slow. Let's however not go into too much technical detail, but ensure that the developers are aware of what's at stake here.

Re: All late projects are the same (2011) [pdf]

#47

Post by 11thEarlOfMar »

The most successful software manager I've worked with, in terms of timeliness, was the one who deconstructed the work the most before starting. What exactly was going to be done, how confident were they in their estimate? Not confident? Break it down more. More detailed requirements, more detailed GUI mock up, More pre-design. Then, when confidence was high enough, by his judgement: who was going to do the work, and how did that work fit into the organization's schedule, including the testing, bug fix cycle needs, test equipment availability, and release.

He was nearly always on time, and never acceded to the customer's desired delivery date unless he could meet it.

I'm not saying this works in all environments, but for his case, it did.

Re: All late projects are the same (2011) [pdf]

#48

Post by mgoetzke »

11thEarlOfMar wrote: post #47

The most successful software manager I've worked with, in terms of timeliness, was the one who deconstructed the work the most before starting. What exactly was going to be done, how confident were they in their estimate? Not confident? Break it down more. More detailed requirements, more detailed GUI mock up, More pre-design. Then, when confidence was high enough, by his judgement: who was going to do the work, and…

Which is indeed successful. But this also takes time and sometimes sadly not allowed or deemed necessary. It also does not allow to respond to changes quickly unless a proper re-calculation is also done. Good technique for a lot of scenarios anyway.

Re: All late projects are the same (2011) [pdf]

#49

Post by snarf21 »

11thEarlOfMar wrote: post #47

The most successful software manager I've worked with, in terms of timeliness, was the one who deconstructed the work the most before starting. What exactly was going to be done, how confident were they in their estimate? Not confident? Break it down more. More detailed requirements, more detailed GUI mock up, More pre-design. Then, when confidence was high enough, by his judgement: who was going to do the work, and…

This can surely work depending on organization. The problem is when the sales people need an estimate in two days or they don't get the contract. Then it is just a wild ass guess and the normal problems ensue.

The reason that software is so hard to do in most cases is that you are making something that (by definition) has never been done before. Of course stuff is going to go bad. This is largely a corporate culture problem. In these cases, I want to have the sales people come to a weekly meeting and have them estimate when they will have 100K sales for the month from new business. I don't think they would like that very much and you'd get a lot of dithering.

Re: All late projects are the same (2011) [pdf]

#50

Post by tombert »

While I 99% agree with the thesis of this post, I feel like another part to why I was late with a ton of projects earlier in my career was due to me getting prolonged depressive episodes, where I didn't want to leave my bed, let alone work on some software I really don't care about. For me, I was later diagnosed with Bipolar II, but it makes me wonder how many people just try and "walk it off" with these things, and as a result their work suffers.
Post reply on HN