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

31–40 of 208 posts

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

#31

Post by andruby »

pjc50 wrote: post #24
cheschire wrote: post #5

Earlier quoted context omitted.

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

And yet, what I see is that enterprise software seems much less polished than consumer software.

My assumption is also that enterprise software contains _more_ bugs than consumer software.

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

#32

Post by andruby »

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.

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

#33

Post by gregjor »

pm90 wrote: post #28
gregjor wrote: post #23

Earlier quoted context omitted.

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.

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, marketing priorities. 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.

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

#34

Post by nonameiguess »

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 underestimate how long something will take, and the problem is exacerbated by management pressure giving them an incentive to estimate even lower.

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

#35

Post by FinanceAnon »

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

> (a) developers did not bother to gather and understand requirements but rushed to start coding

Because of arbitrary and too short deadlines

> (b) poor communication with the customer and stakeholders

Communication is a two way street. Why blame devs for all this?

In my opinion, when a project fails, you have to blame the people higher up in the management chain who are coordinating the work, rather than the engineers. (in a large company)

If engineers are to blame, maybe look at your hiring standards and hire better engineers. This points back to the management again.

> Those faults may come from arrogance or inexperience, or both.

Don't hire arrogant or inexperienced engineers then?

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

#36

Post by bjarneh »

The whole point of organizing things in the first place, is to reduce or remove uncertainty and risk, which cannot be done with software projects.

Software engineering is similar to writing a book, or a movie script; but it is mistaken for some advanced reorganization of numbers in an Excel sheet.

Normal leadership training relies heavily on deadlines to "move things forward", or force us to "see where we are" etc. This only creates stress on the creators themselves, making them far worse at actually creating something. This is something all developers know, and this is why companies started by developers often have a very relaxed attitude towards work. I.e. the dart board, pool table, or beer taps are not there to make the office "look cool", it's there to make a relaxed atmosphere, where you work when you are "in the zone", and relax when you are not.

Everyone who writes movie scripts, books or software knows that you can do more in 4 hours of when you are in "the zone", than in 80 hours in an open landscape, where days are split into short work hours, disturbed by status meetings about progress etc.

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

#37

Post by stupidcar »

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 projects are delayed more than hardware projects of equivalent budget and distinctiveness from previous solutions?

A negative comparison often seems to be made between software engineering and construction, but it seems to me that the latter is a unique subfield of engineering, where you have an unusually large number of projects with a roughly homogenous set of constraints and variables. This has allowed those constraints and variables to be studied, understood and mastered to produce a discipline that more closely resembles mass-production. And in those subfields of software that also involve more homogenous constraints, such as the production of standard commercial websites, you do see a more controlled and templated approach, using tools like Wordpress.

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

#38

Post by gregjor »

FinanceAnon wrote: post #35
gregjor wrote: post #23

Earlier quoted context omitted.

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

> (a) developers did not bother to gather and understand requirements but rushed to start coding Because of arbitrary and too short deadlines > (b) poor communication with the customer and stakeholders Communication is a two way street. Why blame devs for all this? In my opinion, when a project fails, you have to blame the people higher up in the management chain who are coordinating the work, rather than the enginee…

Management may be at fault, but anecdotally I see programmers rushing to code very often. Almost every one of my customers has the same story: the last developers stopped answering emails and calls when the project ran into problems.

I have worked with terrible managers an dysfunctional organizations, but I have seen developers rush to code and stop communicating far more frequently.

I don’t really care about blame. These are people problems with no single solution. When I get involved in a failed project the customer has moved past blame and just wants to salvage something to meet their requirements. The programmers will blame management with little introspection about their own role in the failure.

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

#39

Post by nonameiguess »

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 you might be ruining people's lives. Certain systems need to be robust even if it means businesses might have to earn revenue more slowly. You're not creating value in this case. You're stealing it from your customers.
Post reply on HN