Driving engineers to an arbitrary date is a value destroying mistake (2020) • Hacker News Board

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

#21

Post by bryanrasmussen » Fri, Aug 06, 2021, 9:36 AM UTC

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 the sale the sold off parts were allowed to remain on WestLaw for one year after which they would have had to pay approx. $165,000 dollars a month.

Obviously we got off of by that arbitrary date, and if we hadn't that would have been a value destroying mistake.

on edit: the weird monetary amount is my attempt to turn to U.S.D the DKK amount at the time which was 1 million dkk - iirc the dollar was at a low but it was between 161 - 165.

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

#22

Post by kitsune_ » Fri, Aug 06, 2021, 9:44 AM UTC

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…

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. This is outlined by people like Deming and others in the systems thinking space.

From experience, in their career, engineers not only need to excel technically, but are also forced to pick up everything from UX, methodological BS (from Scrum to Itil) to domain specific know-how in multiple fields or areas. Since many managers do not know what they're doing, senior engineers often times end up being de facto management consultants as well. If you are working in a business environment (as opposed to writing low-level drivers or whatever) it's almost impossible to not pick up on what's going on around you.

How many banking managers know how to code? How many engineers working in banking know at least something about the processes, compliance issues, how the org is structured, what the competitors are?

The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die.

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

#23

Post by gregjor » Fri, Aug 06, 2021, 9:55 AM UTC

kitsune_ wrote: post #22

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…

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. T…

I agree, except the programmer (autistic or not) who wants to be left alone to code and play with shiny things is not just a stereotype. Just read through HN any day to see posts about ignoring meetings, marketing, management, business priorities and focusing excessively on languages, tools, the “best” ways to do things, dismissing non-programmers as hopelessly useless (“many managers do not know what they’re doing.”)

As a freelancer I have to get to know the business my customers are in, I can’t just focus on purely technical things most of the time. Many times I have described my work to other programmers and heard how they want to be left alone to code. I take over legacy software and failed projects for a living. The two main reasons in my experience for software dev project failure are (a) developers did not bother to gather and understand requirements but rushed to start coding, and (b) poor communication with the customer and stakeholders. Those faults may come from arrogance or inexperience, or both.

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

#24

Post by pjc50 » Fri, Aug 06, 2021, 9:56 AM UTC

cheschire wrote: post #5

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…

Just guessing, but I suspect this is because most software is designed to extract some minimum acceptable investment per person from maximum people, and simply focus on scaling. When software is designed to focus on extracting maximum investment per person, and focus on whaling vs scaling, then you get loot boxes. Suddenly overall software quality matters a whole lot to the user base.

> whaling vs scaling

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

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

#25

Post by senko » Fri, Aug 06, 2021, 10:02 AM UTC

kitsune_ wrote: post #22

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…

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. T…

> The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die.

The stereotype has been kicked to death, dismembered, burned, rebuilt as an effigy and burned again throughout the years.

The stereotype of the evil and incompetent manager who is only interested in ruining the lives of their underlings, who would solve the world's problems if only left alone to do their jobs, is still going strong.

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

#26

Post by darkerside » Fri, Aug 06, 2021, 10:04 AM UTC

I'm not convinced an arbitrary date is a bad idea, and in fact, I continue to think it's a good one. If you don't have a point in time you are optimizing for as a developer, then why wouldn't you continue to gold plate and improve your code? Once you have a ship date, you know when it is time to knock it off and start heading downhill.

The real problem here is the leadership deficit. The manager got pushback on the estimates, and instead of explaining the reasoning and bargaining on scope, he caved and kicked the can down the road by letting the estimates crumble. Yes, estimating is hard, and you are probably going to be wrong, but once you have your finger on the scale to get a desired result, you can't blame that on the difficulty of estimating. Just deplorable leadership.

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

#27

Post by rightbyte » Fri, Aug 06, 2021, 10:07 AM UTC

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…

Well it sounds like you are not doing Agile correctly.

Jokes aside I think accumulation of errors together the fact that time estimations are hard and Parkinson's law is the fatal flaws with Agile.

> Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.

This is my experience too. It is somehow easier to estimate big scopes then many small that sums up to the same scope. Also you get a better feeling of how far you have come when looking at the big scope then when digging down to the details.

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

#28

Post by pm90 » Fri, Aug 06, 2021, 10:16 AM UTC

gregjor wrote: post #23

kitsune_ wrote: post #22

Earlier quoted context omitted.

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. T…

I agree, except the programmer (autistic or not) who wants to be left alone to code and play with shiny things is not just a stereotype. Just read through HN any day to see posts about ignoring meetings, marketing, management, business priorities and focusing excessively on languages, tools, the “best” ways to do things, dismissing non-programmers as hopelessly useless (“many managers do not know what they’re doing.”…

> 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.

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

#29

Post by kitsune_ » Fri, Aug 06, 2021, 10:17 AM UTC

senko wrote: post #25

kitsune_ wrote: post #22

Earlier quoted context omitted.

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. T…

> The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die. The stereotype has been kicked to death, dismembered, burned, rebuilt as an effigy and burned again throughout the years. The stereotype of the evil and incompetent manager who is only interested in ruining the lives of their underlings, who would solve the world's problems if only left alone to do their jobs, i…

I agree with you here, but some observations:

Managers are imbued with more formal power than their reports and as such should be held to a higher standard. Simply passing on pressure and not standing up for your team will never inspire loyalty.

Taylorism and top-down management are culturally embedded in many companies. With software eating the world you have companies who are ill-equipped to deal with other ways of working and do not understand how writing software is fundamentally different than building a house. This all inevitably leads to cultural conflicts.

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

#30

Post by pjc50 » Fri, Aug 06, 2021, 10:18 AM UTC

danparsonson wrote: post #12

Alternate view point - driving projects to a specific deadline allows the other departments in the company to coordinate marketing, packaging, and selling the product. These people don't sit on their hands patiently waiting for engineers to finish building, their work can take many months just as the development does, and sometimes also involves making tradeoffs to deliver on time. No company wants to wait another ye…

Yeah, this is an unfortunate truth that Agile has to confront; there may be hard coordination deadlines. Or, in startups, a financial "runway".

On the other hand, setting a deadline can't force something to be possible, it can only force people to work harder and more painfully towards it. I'm sure the Amazon drone delivery failure had a date target, for example. And there have been plenty of failed "big bang" IT migrations delivered by similar immovable deadlines.