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

91–100 of 208 posts

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

#91

Post by grepfru_it »

ChrisMarshallNY wrote: post #86
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…

Yes, I've been writing it alone, but my "alone" work is at a different level, from what many folks do. Approaching every bit of work I do as "ship," is one of my oddities. I have as much fun, shipping , as I do writing. I consider everything I do, "engineering." Been doing that, all my adult life. Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a numb…

I hear you, but this problem becomes exponentially harder as your engineering org grows.

I witness on a daily basis PRs that have no body getting merged with absolutely zero comments and a blanket approval as long as it passes our (broken) CI pipeline. I witness obvious poor quality in the code, but engineers want to seem like they are working and will just blanket approve PRs, while i'm in the middle of writing up my code review denying the PR.

If you are a developer on a team and want your codebase to be high quality, you end up no longer writing the code and instead spend all of your time gatekeeping via code reviews. This leads to burn out.

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

#92

Post by uglygoblin »

gregjor wrote: post #33
pm90 wrote: post #28

Earlier quoted context omitted.

> Just read through HN any day to see posts Only an incredibly tiny slice of professional engineers are on HN, even smaller slice of that actually post anything. HN is not representative of anything.

For most of my 40 year career as a programmer HN didn’t exist, but the complaints about management and business priorities did. And so did those stereotypical developers who want to be left alone to play with shiny things. You can find the attitude I described all over the place, not just HN. When I get involved in a failed or failing project the developers almost always blame management, schedules, budgets, marketin…

> They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for.

I think the quoted statement tends to be a systematic issue on struggling projects that describes the decision makers, regardless of role.

I'm not sure how anybody can expect other outcomes than a few lucky successes and a lot of failures when understanding why you are building something seems to be undervalued by management, technical or other.

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

#93

Post by ChrisMarshallNY »

grepfru_it wrote: post #91
ChrisMarshallNY wrote: post #86

Earlier quoted context omitted.

Yes, I've been writing it alone, but my "alone" work is at a different level, from what many folks do. Approaching every bit of work I do as "ship," is one of my oddities. I have as much fun, shipping , as I do writing. I consider everything I do, "engineering." Been doing that, all my adult life. Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a numb…

I hear you, but this problem becomes exponentially harder as your engineering org grows. I witness on a daily basis PRs that have no body getting merged with absolutely zero comments and a blanket approval as long as it passes our (broken) CI pipeline. I witness obvious poor quality in the code, but engineers want to seem like they are working and will just blanket approve PRs, while i'm in the middle of writing up m…

Yeah. It can be a real challenge, ensuring quality on a team.

The obvious answer, is to hire experienced, skilled, capable engineers, and instill in them, the same reverence for Quality that you have.

Like I said, Quality is expensive. Very few companies like to pay the premium.

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

#94

Post by Retric »

dagw wrote: post #79
Retric wrote: post #72

Earlier quoted context omitted.

I am not saying it’s easy to beat them, rather first movers also generally die or move on. Atari, Electronic Controls Company, Mosaic, etc simply aren’t around any more. Sure Yahoo isn’t dead, but it’s also moved on from it’s initial success.

first movers also generally die or move on. Sure, but before that they generally make a lot more money than the second and third mover. When all is said and done, Atari and Yahoo did much better than Colecovision and Lycos. The risk with being the first mover is that, having easily seen off competition from the second and third mover, you become complacent and stop moving.

Many arguably most first movers simply flopped, look at social networks or MMO’s for example. The bias of only remembering successful first movers is exactly the illusion I am talking about. Generally if a slightly different business model works it’s a first mover if it fails it’s a bad idea.

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

#95

Post by zug_zug »

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…

Yeah, if I could go back in time I'd tell myself "Software has always been late, it's always going to be late, you can work yourself extra-hard to make it less late, but it's not YOUR PROBLEM. You can compensate for the malfunction of the organization but you won't be thanked, you won't learn as much by hacking, and it almost never matters anyways because the startup either will get traction or it won't, it never fails by a margin of 5%"

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

#96

Post by occz »

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…

I like what Peopleware says on the matter - the market has squarely selected low quality software over high quality, but if you try to drive your teams to build low quality software you will lose because you will be unable to retain good developers.

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

#97

Post by stephc_int13 »

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…

This is why this is counter intuitive.

We're trained to cut big problems in small parts to solve them.

This is more closely related to human psychology than pure logic.

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

#98

Post by moonchrome »

ChrisMarshallNY wrote: post #90
onion2k wrote: post #82

Earlier quoted context omitted.

Professional developers should strive to write the highest quality code they can given the constraints of the project. That's pretty much a given. I'm only arguing that customers don't seem to care, not that we shouldn't care.

Exactly. I read a book, where one of the characters is a smith. It has this exchange, between him, and another character: "Always do the very best job you can," he said on another occasion as he put a last few finishing touches with a file on the metal parts of a wagon tongue he was repairing. "But that piece goes underneath," Garion said. "No one will ever see it." "But I know it's there," Durnik said, still smoothi…

One reason I like this kind of work is that it implies when someone spent that much effort on an irrelevant detail they probably paid attention to important parts as well. Not always the case but yeah.

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

#99

Post by jdbernard »

nonameiguess wrote: post #41
bryanrasmussen wrote: post #21

this seems to mainly be relating to pushing to an arbitrary date for creating something new but still sometimes dates are given to us because of some sort of regulatory reason or a company contract meaning that something needs to be done by a certain time - before anyone says don't make contracts like that: The Danish and Swedish parts of Thomson Reuters WestLaw were sold off to an English holding company, as part of…

Also government contracts, at least in the US, have to be authorized by an appropriations bill from Congress. A federal agency can't just go to Congress and ask for an unknown amount of money to deliver a capability at an unknown date. Whether it ends up being right or not, and probably it usually isn't, appropriations bills have to be time-bounded and include a maximum dollar amount, and the awarded contract can't g…

In which case it would be wise to be extremely conservative in your estimation, taking initial engineering estimates and padding them further, not whittling them down. Because a baby takes nine months and can't be safely rushed out in six no matter the acts of congress, presidential edicts, and demands from the grand poobah.

If you fix the dates, something else has to give. If time, cost, and scope are all fixed you're going to fail, almost guaranteed. There are always unknowns and in this scenario the only thing you've allowed to flex is quality.

I'm not saying you can't come in on time and under budget. This article spells out the dysfunctional dynamic of date pressure. By creating this much pressure from the beginning, you create an environment when corners are cut from the beginning and the problem compounds over time. The pressure-cooker mindset of management kills the quality of the project, even if the estimates did turn out to be reasonable.

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

#100

Post by datalus »

tkiolp4 wrote: post #83
ChrisMarshallNY wrote: post #77

Earlier quoted context omitted.

Personally, I write software that I consider extremely high-quality. The folks that use it, seem to agree. It isn't eye-candy fancy, but it works very well, in a not-in-your-face manner. The idea is that it does what it says on the tin, without fanfare, robustly, usably, accessibly, localizably, and dependably; providing a user experience that gets out of the way of the user, in a manner that does not surprise the us…

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.

Post reply on HN