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

161–170 of 208 posts

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

#161

Post by spaetzleesser »

danparsonson wrote: post #80
Forge36 wrote: post #55

Earlier quoted context omitted.

I business agreement isn't an arbitrary date. Those dates should be clearly communicated to engineers.

They are communicated to engineers - in the form of deadlines...

Problem with a lot of deadlines is that you aren’t told if this is a hard requirement because of a contract or some other external factor or just an ego trip or wishful thinking of upper management.

I have seen it plenty of times that management pushed for an arbitrary deadline. The deadline passed, project was not done and nothing bad happened other than another new deadline.

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

#162

Post by spaetzleesser »

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…

My formula is usually to listen to the project idea, talk to a few people, take my first feeling how long it could take and then multiply by 5. This usually is pretty accurate.

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

#163

Post by liketochill »

taneq wrote: post #141
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…

> It seems strange to me that software engineers are so frequently singled out for schedule slippage It follows this trend I've seen across the board in business throughout my career, of mistaking the last hair on the last yak for the entire job. The classic example is documentation. "Hey the electrical drawings are due on Thursday the Aprilteenth, can you have them ready by then?" Oh sure, that's two months away, th…

I’m also in industrial automation and know the challenges of being “last” in years long projects.

We are very deliberate about setting deliverable dates in time after the required inputs by others are available, and when inevitably they are not, we have a spreadsheet sent to the customer every 2 weeks which shows what information we are missing and the delay that is causing to our progress. As we are liable for damages if we delay the project it is necessary for us to have the proof that we did not cause the project to be behind schedule. This often means having these difficult conversations only a month in to a year long project when vendor drawings we were promised are not delivered.

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

#164

Post by ChrisMarshallNY »

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.

I'm the poor schlub that usually needs to maintain the code that I write.

I also pretty much never get questions about the code that I pass on to others.

I write about my process here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

(Long screed. Few read it).

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

#165

Post by tikhonj »

gregjor wrote: post #17

Which is more likely: Businesses invent truly arbitrary deadlines for the hell of it, or the “engineers” don’t want to pay attention to business requirements and competitive pressures? When so-called engineers stop spending half the development schedule choosing a framework and the other half trying to make their dev setup work on everyone’s personalized laptop they will have some credibility complaining about “arbit…

Businesses—in the guise of mediocre managers—absolutely invent arbitrary deadlines as a mechanism of control. If the deadline were real, it would have context, engineers could use that context to adjust the scope and design of what they're building and we wouldn't be having these conversations in the first place.

The problem begins when deadlines are used to limit agency rather than support it.

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

#166

Post by Rd6n6 »

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.

In Canada, engineer is a protected title. There are software engineers and you get professors who stress to you the importance of testing and safety, and there are safety and ethical requirements. It’s not very strongly enforced though, lots of people here get away with using the title

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

#167

Post by brightball »

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 about how to trim your requirements to have a shot at hitting it.

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

#168

Post by motioncuty »

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.

I mean, I'm and audio engineer, a fire protection engineer by degree, and a software engineer. Your bridge building analogy doesnt hold up, there is always changes and refinements of guestimations.

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

#169

Post by Trasmatta »

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.

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

#170

Post by Jtsummers »

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.

It's the confusion of estimates and plans with commitments. "How long will this take?" "About a week" "Great, ship it Monday morning" "Wait, if it has to be Monday then let's spend 30 minutes figuring out what needs to be shipped and what can slip until a later update release" "No, you said a week".
Post reply on HN