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

51–59 of 59 posts

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

#51

Post by chimprich »

codycraven wrote: post #12
rossdavidh wrote: post #9

Earlier quoted context omitted.

I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.

I have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated. The biggest pet peeve is when I give an estimat…

It doesn't get a lot of love on HN, but these problems are addressed by Scrum. Sprints have a pre-allocated amount of work in them, which makes estimating easier. You can't predict exactly how much time you'll lose through meetings and emergencies, but estimating in story points will add a rough statistical estimate.

Of course, if you already have a toxic development culture like the one you describe, then they'd probably abuse more agile processes too.

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

#52

Post by rossdavidh »

wwweston wrote: post #27
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.

You could argue that these are some of the many forms of "starting late": * If you just don't know how long something is going to take, and you need a date, then you're late to doing the work to know how long it will take. * If you do know how long something is going to take, and it's longer than a externally imposed date, then you know exactly how late you are. This is partly just playing with semantics, but it's al…

In at least some cases, you have to be halfway into doing the work (or more) before it becomes apparent that there is a big, previously-unknown subtask or requirement that invalidates the plan for doing it. In other words, if you really know enough to give a good estimate, you are probably mostly done.

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

#53

Post by tworc »

We work, live and operate in a complex environment and I think if we start viewing the organisation its projects and the environment in which it operates more from a systems perspective we may realise that in fact, it is truly difficult to make accurate predictions given the non-linear behaviour the system exhibits that results from all the information flows (or lack thereof), interaction of parts and other dynamics such as markets, human energy levels/mood, etc.

I really learned a lot from the book called Thinking in Systems and nowadays I can't help to look at projects, from within the context in which it operates. Definitely recommend the book for somebody wanting a bit of an introduction to that mental model.

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

#54

Post by bartread »

jadedmgr wrote: post #14
mden wrote: post #7

Earlier quoted context omitted.

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…

As a manager over a new project with a ridiculous release date, I'm subject to the same political bullshit as everyone else. At this point, I'm of the opinion that anything with a realistic ship date simply won't get funded. So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place. From that poi…

> I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.

On one level I have to take my hat off to you because you sound like exactly the kind of manager - one who has your team's back - that a lot of people would want to work for.

On another level you're part of the problem: you're wasting organisational resources that could be better and more profitably used elsewhere.

Still, needs must I suppose, because the real fault here - as the article itself hints - is in the determination of what the most valuable use of everyone's time is. I.e., if projects are going to be late (and they are) then you ought only to deploy teams to work on the ones with a putative 10x ROI.

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

#55

Post by wwarner »

ryan-allen wrote: post #15
wwarner wrote: post #6

Earlier quoted context omitted.

Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.

> but I'm a firm believer in selling first and building it later Please elaborate! :)

In a word, it's "agile".

Let me first acknowledge that there my thoughts are a mixture of the types of projects that I've been working on, my own personality and my own path dependent experience. In particular, my way is intentionally short sighted and won't work for a project plan that takes five years. Also, for sure, if the sales team/ceo is wrong and the project isn't worth doing, then doing it "lazily" won't fix that. But with that out of the way, here's what I mean.

The engineering team has it's own values and priorities and they just don't have anything to do with what really matters to customers. In the end, everyone brings in emotional baggage from the last project they worked on, and that's what's important until new information comes in from customers and the sales team.

So what I shoot for is taking the requirements that we have and producing a long range design that will meet those and little more, and then producing features as quickly as possible and presenting it to the customer (or the customer's advocate).

Why does it limit scope? Because the deadline doesn't move! To meet the most important requirements in a way that actually sells the product, lower priorities are are cut or reframed.

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

#56

Post by jayd16 »

kgilpin wrote: post #41
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.

That's still an estimation problem by management. In agile, all sides are supposed to understand that scope and timeline are constantly adjusted.

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

#57

Post by heavenlyblue »

snarf21 wrote: post #49
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…

The question is whether you're working for a sales company or a tech company.

Sales companies will prioritise the requirements of sales people, and tech would prefer to ignore the sales guys.

Frankly, as an engineer - I would never prefer the company where the sales people can decide how much overtime I would be doing in the end. Also - they would be getting all of the bonuses, since it's them making the decisions in the first place.

The good thing I find is that working for the engineering companies usually implies having clients with a head on their shoulders (hence them knowing what they want and what they're getting; and how much time it usually takes).

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

#58

Post by mekane8 »

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…

I found Steve McConnell's (of Code Complete) breakdown of estimates, targets, and commitments super helpful: https://www.youtube.com/watch?v=FY9X21HA02w

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

#59

Post by wwweston »

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…

Or in other words: a good estimate is itself a project.
Post reply on HN