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

51–60 of 208 posts

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

#51

Post by inglor_cz »

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…

To list just a few such slipping projects outside the software realm:

* Space Launch System

* Boston's Big Dig

* New Berlin-Brandenburg Airport

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

#52

Post by illuminati1911 »

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…

” A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.”

I’d say better way to say the same thing would be ”Unless you are building something truly innovative and unique that people must use anyway no matter how bad the experience is, software quality matters.”

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

#53

Post by thow-01187 »

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…

Furthermore, financial penalties on late delivery are not uncommon in enterprise business-to-business settings. These penalties are sometimes quite steep

If the choice is between releasing kinda-working, but unpolished software, or throwing a developer's monthly labor cost out of the window every single day, these management anti-patterns suddenly make much more sense

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

#54

Post by Closi »

tuxie_ wrote: post #13
Closi wrote: post #11

Well the counter argument is that shipping later also destroys value (because value can only actually start to be accumulated once a product has shipped). But this article doesn't seem to address the obvious counter-point. For instance, take the below: > wouldn't you rather run a your customer's payments through code that is at least attempting to handle error conditions, rather than some happy path code that just as…

"destroyed" and "not created" are not synonyms, they can't be used interchangeably as you do here. This invalidates the argument for me to be honest.

Well the article talks about examples of 'destroying value' being projects that failed to go live, which would be 'value not created' to your point (it's not my choice of language, I was just following the article!). If it invalidates my argument I assume it invalidates the article too.

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

#55

Post by Forge36 »

thow-01187 wrote: post #53
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…

Furthermore, financial penalties on late delivery are not uncommon in enterprise business-to-business settings. These penalties are sometimes quite steep If the choice is between releasing kinda-working, but unpolished software, or throwing a developer's monthly labor cost out of the window every single day, these management anti-patterns suddenly make much more sense

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

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

#56

Post by namdnay »

illuminati1911 wrote: post #52
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…

” A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.” I’d say better way to say the same thing would be ”Unless you are building something truly innovative and unique that people must use anyway no matter how bad the experience is, software quality matters.”

The thing is, 90% of software is “unique”, in the sense that it solves a specific business requirement

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

#57

Post by Closi »

nonameiguess wrote: post #39
Closi wrote: post #11

Well the counter argument is that shipping later also destroys value (because value can only actually start to be accumulated once a product has shipped). But this article doesn't seem to address the obvious counter-point. For instance, take the below: > wouldn't you rather run a your customer's payments through code that is at least attempting to handle error conditions, rather than some happy path code that just as…

I really don't like this conclusion. I guess this is why we need financial regulation, because rushing through a buggy payment system so you can make a buck quicker is how customers get their accounts hijacked and identities stolen. Maybe as an early-stage investor or company founder, it makes no difference to you because you'll exit before anything ever hits the fan and the law will never hold you accountable, but y…

The article is talking about integrating a payment gateway, so I don't think this specific risk is valid but the overall point is right - yes, there is a trade off between speed to market and how many workarounds will be required.

The truth is that sometimes speed to market is more important than quality, and visa-versa. Handling sensitive credit card data? Sure quality and security are important of course. Implementing a payment gateway to bootstrap a company where that is 1 of 100 tasks before go-live? Hack away and go as fast as possible, and worry about improving it later!

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

#58

Post by Lorkki »

andruby wrote: post #32
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…

You are right. Solving the right problem the wrong way is more important than solving the wrong problem the right way. As an engineer, that has been one of the most important lessons for me in my career so far.

Or: Assuming a vacuum, solving the right problem is more important than solving it the right way.

But also, solving it the wrong way may create an opportunity to do better.

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

#59

Post by namdnay »

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…

It’s funny you say this because every software project estimate I’ve ever done has basically been to invent lots of small bricks and fiddle the numbers of these so the total matches what seems to be the intuitive size

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

#60

Post by papito »

This is a combination of management not asking for input, pulling a deadline out of their asses, and engineers chronically low-balling their own estimates (while the managers think it's the opposite).

My pet peeve is when a deadline is a "round" date. 1st of the month, 1st of the year. WHY? Your users don't give a shit. If you are not publicly committed to a launch date, which you should never be, until your product is ready.

That said, internal deadlines are a moronic thing to have. These should be goals.

Post reply on HN