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

Driving engineers to an arbitrary date is a value destroying mistake (2020)

iism.org

Post reply on HN
Print view View original

171–180 of 208 posts

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#171

Post by stronglikedan »

namdnay wrote: post #59
stephc_int13 wrote: post #18

There is a counter intuitive thing about software project estimation that took a long time for me to discover. The more rigorously you try to analyse the problem, cutting it into smaller and smaller parts, the more error you introduce, reducing the value of the estimate at each step. Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences. If you don't have…

It’s funny you say this because every software project estimate I’ve ever done has basically been to invent lots of small bricks and fiddle the numbers of these so the total matches what seems to be the intuitive size

yup, me too...then double it

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#173

Post by brightball »

Trasmatta wrote: post #169
brightball wrote: post #167

Yep. I’ve preached this whenever I talk about dev process. The best way I’ve heard it framed was using two different terms: deadline and target date. Target dates are internal goals, not tied to anything other than a rough estimate or a day somebody made up. Deadlines are tied to contractual obligations, events, etc. If it’s not a real deadline it’s a target and targets can move. Real deadlines mean you start talking…

In my experience "target dates" have a funny way of transforming themselves into deadlines over time.

Like most things, it depends on leadership beating the dead horse to constantly remind people of the difference.

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#174

Post by SpicyLemonZest »

bcrl wrote: post #115
stupidcar wrote: post #37

It seems strange to me that software engineers are so frequently singled out for schedule slippage, when the impression I get is that every novel engineering project suffers from the exact same problem. Projects to design and build new military and civilian hardware and infrastructure always involve budget and schedule overruns of months or years. Can anyone provide convincing empirical evidence that software project…

I think there's a difference between companies that build software for the market versus those that build software for a contract . The former tends to be driven by a team that believes in the product that they're trying to deliver, has a management team that has at least some vision for the software and investors that believe in the company's approach to the market. They want to make software / a product that repres…

I think you'd be surprised to see how much of the roadmap at a typical "build for the market" company is driven by specific contracts. In my experience, the proportion is high even in consumer tech, and easily clears 75% for even the most commoditized of enterprise software. The stereotypical contract shop is distinguished more by poor planning and an aversion to shared architecture than any real difference in incentives.

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#175

Post by rocmcd »

liketochill wrote: post #159
pavlov wrote: post #63

Earlier quoted context omitted.

The Olkiluoto 3 nuclear power plant in Finland. It’s a new type of reactor and one of the only nuclear projects in the West. Construction started in 2005 and the plant was supposed to be online in 2010. Eleven years later it’s still not operational. Original budget was 3 billion euros. Current estimate is over 11 billion.

Wise moves on the part of the project proponent, had they presented their project with a 17 year construction and 11 billion euro budget it never would have been started. Humans are optimistic. If we knew in the beginning how long something will actually take we never would start many things.

This is the "hiding hand" principle at play.

https://en.wikipedia.org/wiki/Hiding_hand_principle

I highly recommend anyone interested in "megaprojects" to listen to this EconTalk podcast episode with Bent Flyvbjerg:

https://www.econtalk.org/bent-flyvbjerg-on-megaprojects/

Very insightful conversation.

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#177

Post by coffee »

onion2k wrote: post #3

The problem that the article doesn't address is that users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it. I could list literally hundreds of half-assed, broken, bloated applications that I've encountered in the past 25 years that have done very well simply because they kind of solve a problem a bit for the user. Pushing out something completely…

> The problem that the article doesn't address is that users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it. I could list literally hundreds of half-assed, broken, bloated applications that I've encountered in the past 25 years that have done very well simply because they kind of solve a problem a bit for the user.

This is ZERO snark, but I'm genuinely curious for lots of examples. I ask because I'm confronted with this problem ALL THE TIME working at startups that obsessively focus on visual elements that won't move the needle, versus being obsessive about solving pain better than others.

I need to start building a list that I can just pull out at a moments notice.

Would love to hear more!

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#178

Post by cfcfcf »

datalus wrote: post #100
tkiolp4 wrote: post #83

Earlier quoted context omitted.

You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…

I would say a lot of this confusion comes from the word engineer. Building software is not like building a bridge. You can't design it first and then go and build it. So I would say engineer is a poor term, but also the only one we've got for now.

Yes, I personally find developer or programmer more accurate, although neither is without its own connotations and baggage.

As a designer I’m a bit embarrassed by the trend to describe ourselves as product designers. To me a product designer makes chairs and coffee tables.

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#179

Post by crucialfelix »

andruby wrote: post #31
pjc50 wrote: post #24

Earlier quoted context omitted.

> whaling vs scaling This is a great phrase that I'll have to remember. Pretty much all enterprise sales is "whaling".

And yet, what I see is that enterprise software seems much less polished than consumer software. My assumption is also that enterprise software contains _more_ bugs than consumer software.

I am guessing it has to do with the style of product managers in enterprise. A lot more non-technical PMs, people with BI backgrounds?

Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)

#180

Post by tkiolp4 »

shalmanese wrote: post #146
jagged-chisel wrote: post #87

Earlier quoted context omitted.

I don't like this definition of Software Engineering that necessitates a team of Other People. Perhaps I'm outright wrong that such a definition just shouldn't be. Even in that case, I just don't like it. :)

If you broaden the definition of Other People to "you, 6 months from now" and "you, 6 months ago", then many SE principles still apply. Where SE principles don't apply is toy, one off scripts that you just hack together to get a single thing done and require no maintenance like a lot of stuff in science.

Strangely enough, software engineering is mostly about humans rather than about software. Take any side project of yours (no matter if it has been hacked together or if the best practices out there have been applied): add pressure to make money out of it, pressure to deliver it at a given date and a bunch of individuals you must collaborate with to push the project live, and right there you get SE.
Post reply on HN