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

141–150 of 208 posts

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

#141

Post by taneq »

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, that's plenty of time to bang out some drawings, right? But wait! The drawings depend on the functional specification. And the functional specification depends on the functional description. And the functional description is blocked on some TQs from the client. And you're still expected to produce these drawings by Thursday Aprilteenth when realistically you're not going to see even a first draft of the functional specification until the Wtf'th of August. But now it's your fault that the drawings are late because you weren't paying attention and you agreed to a due date that didn't depend on your dependencies.

I take this one particularly personally because I'm in industrial automation and, almost by definition, we get the last bite of the pie on every single project. Sure, there are some things we can start early but on the project-specific parts, generally we're waiting for everyone else to do their job before we get priority.

"Can you help us with the motion control software for AwesomeBot?"

Sure, no worries!

"Just remember we need AwesomeBot running by Thursday."

Hey cool, you present me with an AwesomeBot-shaped shell and I'll fill it with closed-loop-ey goodness.

"It's Friday, why isn't AwesomeBot doing somersaults like you told us it would?"

Uh well, AwesomeBot is lying disassembled on the mechanical workbench and half the laser cut sheet metal hasn't arrived.

"But you told us Thursday! Okay, we'll finish putting AwesomeBot together and let you know when it's done."

"Hi remember us? We're AwesomeBot inc."

Oh hey how's it going with that?

"We've got AwesomeBot fully assembled and we're ready to go! Can you come down tomorrow and install the software on it so it does everything we ever dreamed of including anything we might have imagined it might do in the 17 months since we last saw you?"

Uhhhh... so how's testing going, have you switched it on yet?

"No, why would we do that? We were only waiting for you!"

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

#142

Post by taneq »

altitudinous wrote: post #42

Once you've been around in this software business for long enough you see the same articles written over and over again... there will always be articles about estimating software, yet there is no solution to this problem. Anyhow, it doesn't matter. Software devs are the lowest cog, they don't get to extend the delivery date. All the layers above - management, marketing, sales etc need a date to work to to deliver the…

> Once you've been around in this software business for long enough you see the same articles written over and over again

My favourite is watching successive generations discover thin client vs. fat client over and over again.

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

#143

Post by bishoprook2 »

iso1631 wrote: post #138
bishoprook2 wrote: post #75

Earlier quoted context omitted.

>The problem that the article doesn't address Another. Industries that are oriented towards tradeshow or holiday launches. It ain't like they're going to move NAB or Christmas just for you. Inevitable feature pruning occurs. Having said that, I wonder how many of the great fortunes have been built on horrid, half-finished websites and associated software that were all about being first out of the gate and heavy marke…

October will be interesting, wonder how busy NAB will be. I know one supplier from the UK who's planning on quarantining in the carribean for 2 weeks ahead of NAB because the US still wont let people from Europe in (other than Nigel Farage)

I think that eventually the vendors will decide that it's a waste of money.

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

#144

Post by jerf »

nonameiguess wrote: post #34
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…

Theoretically, this should be the exact opposite of the truth. Breaking a big prediction into a whole lot of smaller predictions is the basic intuition behind Fermi estimation and wisdom of crowds. As long as errors are symmetrically distributed and independent of each error, they'll cancel each other in aggregate. The problem is estimation errors are not symmetrically distributed because engineers chronically under…

They're also not symmetrically distributed because delays are much larger than surprise wins. A win of 50% and a delay of 50% is already non-symmetrical, because the delay will be quite a bit larger, and the real numbers are even worse. A 5x delay on a particular element would be unsurprising, but to estimate something and then have it surprisingly cut to 1/5th the time is something I've only seen a handful of times in my career. "Oh! There's a library in the code that already does exactly this!"

The distribution of delays is pathological, too. It's not normal or poisson or anything nicely amenable to analysis.

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

#145

Post by jdauriemma »

The most effective manager-engineer relationships I've seen are built upon a problem-solving culture, rather than feature-shipping. If your goal is to solve problem X in Q3, your managers and engineers have far more flexibility to collaborate and compromise. If your goal is to ship X features in Q3, your managers have less flexibility and your engineers have an incentive to cut corners.

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

#146

Post by shalmanese »

jagged-chisel wrote: post #87
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 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.

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

#148

Post by Retric »

iso1631 wrote: post #139
Retric wrote: post #64

Earlier quoted context omitted.

The first mover advantage is an illusion. Google didn’t invent search or online Email. Microsoft didn’t pioneer personal computing, spreadsheets, or word processing. Facebook wasn’t the first social network. Apple made most of it’s money from markets it entered late iPod, iPhone, and then iPad where the Newton failed. Intel wasn’t the first to build a microprocessor. IBM didn’t invent the computer.

Google search was two orders of magnitude better. Gmail launched with 1G storage when hotmail offered 10M. Both products launched with exponentially growing customer base too. Despite that, hotmail still exists. While first mover doesn't guarantee success, it's certainly an illusion.

Two orders of magnitude is a serious exaggeration. I remember swapping back and forth through multiple search engines well after Google showed up. Search index size and update frequency used to be a much larger issue for me.

Early on I swapped from yahoo mail to gmail to hotmail because gmails spam filtering wasn’t good enough. Among my fiends Gmail really won on UI not space.

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

#150

Post by bob1029 »

There is never going to be one clear way to deal with scheduling around software projects. The number of variables involved is vast.

I view schedules around software projects as a few different things:

- Public expectations for specific deliverables that your customers can align to, many times with a calendar unique to each customer.

- Internal carrot/stick for managing constraints around active feature development. If you have an infinity budget (film/AAA gaming), you might be able to run less-bounded parallel efforts as noted elsewhere in this thread.

- Orthogonal operational concerns (planned outages, et. al.)

- Roadmap for strategic product development that the investors can think about

So, when someone says something to me like "are we still on track for end of the week?", I have to provide an extremely qualified series of responses and ask more questions.

Post reply on HN