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

121–130 of 208 posts

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

#121

Post by taneq »

dangerface wrote: post #101

There is nothing wrong with working to dead lines estimating and planing development and releasing software thats good enough not perfect. The problem is when people start trying to change the plan half way through execution, non tech people will constantly try to do this because they are clueless its the project leads job to tell them no. When your manager asks you "if anything can be done to pull those dates in." y…

> I know its scary being blunt with your big boss but as a senior developer thats your job.

This. They could hire any random chump to say they're right. If you're the expert, they hired you to tell them whether they're right.

Of course, not all managers understand this but the sooner you realise you're working for one who doesn't, the better.

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

#122

Post by ordu »

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.

As I see it, it is more nuanced. When engineer designs a bridge she does a very similar work to a programmer. Programing it is like designing a very complex bridge without constructing it really, because when you finished your design it had been built already.

So it is not exactly like you've said:

> You can't design it first and then go and build it.

You can design, but you cannot build.

A process of building by a design can be paralleled with deploying software -- suddenly there is a hairy real world, not all the hair was considered at the design phase, and either we hack around existing software (i.e. design plans), or call a programmer to redesign.

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

#123

Post by kongolongo »

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 agree with that last sentence, but IMO even in a well-served market things like brand loyalty, familiarity, and social momentum can often be major deterrents to switching just for the sake of quality and often times unless the major players in a market are really messing up users will not see much of a reason to switch.

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

#124

Post by waynesonfire »

umvi wrote: post #118
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…

It's easy to make high quality software as a team of one - you never have to compromise, after all. You are basically a god of the project. When working on a large team though you have to make all sorts of trade offs at all sorts of levels and it's way harder to produce high quality software because you are no longer a god that controls every single aspect of the project.

I don't buy it. You don't have to own the _ENTIRE_ application to be a developer of one. I've seen many developers that were solely responsible for a specific feature and shipped what I'd consider poor quality.

Large software project, whether you're a developer of one or a team (and probably more commonly occurs in a team since it's large) will have warts. It's harder to manage complexity as the projects size increases since it accumulates and it accumulates fast.

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

#126

Post by 52-6F-62 »

mwcampbell wrote: post #110

> The Big Boss is a pressure kind of guy, he believes that people work best when they are under pressure and if pressure isn't applied, they waste a lot of time on unnecessary things. [...] he goes away thinking what he already knew, that engineering is just screwing around instead of getting the project done. Sadly, he's often not wrong. My own work ethic isn't exemplary, and sometimes in the absence of pressure I s…

Reframe the question: is it slacking off or is it restorative mental break?

Just speaking for myself, but I think better when I'm not pinched between two projects both demanding preference and priority over the other. I can maintain a clearer mind when I don't have people breathing down my neck about deadlines they set and then broke.

Sure, one learns to navigate those situations and maintain an even keel, but still one is obligated to respond in a professional manner to those inquiries and meetings and other emotionally manipulative games people play to get their way when in a crunch. Working through those things still requires time out of day and energy out of mind. Both of those latter resources are limited.

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

#129

Post by wmeredith »

mprovost wrote: post #78

When I was in the VFX world we had fixed, hard deadlines. Once the release date is printed on a movie poster it's not changing. Some parts of the process were easy to estimate since they'd been done many times before, but on every film there were some experimental new things. Often they would just end up with 2 or 3 different teams working on the same problem. One with a known technique, and one or two trying somethi…

"In the eyes of those who anxiously seek perfection, a work is never truly completed—a word that for them has no sense—but abandoned; and this abandonment, of the book to the fire or to the public, whether due to weariness or to a need to deliver it for publication, is a sort of accident, comparable to the letting-go of an idea that has become so tiring or annoying that one has lost all interest in it."

–Rosalie Maggio

Source: https://quoteinvestigator.com/2019/03/01/abandon/

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

#130

Post by TeMPOraL »

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…

> Users mostly don't care so long as the app works well enough to do what they need it to do (but they're not dumb, they'll still pick the least buggy option if there are alternatives..).

In other words: users do care. They just don't have a choice.

That's not the same than users "not minding" bad software.

Post reply on HN