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

41–50 of 208 posts

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

#41

Post by nonameiguess »

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 go longer or higher no matter what the engineers think it will actually take.

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

#42

Post by altitudinous »

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 their work, and they generate the $$$. No-one cares if the software is low quality, as long as it is delivered. Dev team can do further updates to bug fix after delivery. The end.

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

#43

Post by cheschire »

andruby wrote: post #31
pjc50 wrote: post #24

Earlier quoted context omitted.

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

That's probably why articles like this get written so often. The companies who create enterprise software seem to think they're still working on scale.

And I don't intend my loot box reference to be taken too seriously. The gaming industry isn't any better. As an obvious example, Cyberpunk 2077 was delivered as a hot mess only to meet overhyped timelines.

But look at games like Apex Legends, Fortnite, etc. They work very diligently to ensure the core gameplay is solid so streamers will provide eyeballs, driving lootbox sales. Whales provide the biggest investments there, with some individuals spending thousands of dollars for cosmetic lootboxes in what would otherwise be a free game.

Then look at games like Quake Champions which should've been successful in the same way, and completely failed because they didn't focus on making the core game tech (net code specifically) rock solid before attempting to monetize. They immediately lost the pro crowd and failed to convert the people playing Quake Live (or even the die hard Q3A players).

Enterprise software often doesn't spend enough time improving core process loops, or worse, provides too many core loops making the experience disjointed and unproductive.

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

#44

Post by quickthrower2 »

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…

No one gets to choose the delivery date, other than actual reality. Anything before that is a prediction. The question is how good is your predictive model and do people understand the error margins. In my experience high ups like to promise dates (in general). But it’s a dance: everyone knows it’ll be later because “IT project”

It takes a lot of trust and maturity and skill (from both technical and business side) to have continual value delivery instead of estimates. This is possible but not the common case.

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

#45

Post by pjc50 »

andruby wrote: post #31
pjc50 wrote: post #24

Earlier quoted context omitted.

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

Yes, the "whale" is the single huge client who pays a lot of money for the enterprise software. The client is not the users. The sales pitch for enterprise software is where the polish goes.

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

#47

Post by amelius »

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.

And don't get me started on security/privacy issues.

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

#48

Post by narag »

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…

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've been saying that for a long time, but I don't see as a problem in itself, but as a fact of life.

The problem comes because people get the wrong impression that "state of the art" is always a compliment and terrible usability is best of possible worlds.

I'm reminded of this every time I try to teach my mother anything about Android or Windows. Or even when I must deal myself with a new app with its quirky "state of the art" GUI.

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

#49

Post by righttoolforjob »

gregjor wrote: post #38
FinanceAnon wrote: post #35

Earlier quoted context omitted.

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

I do disagree. The primary responsibility of the manager is to manage and to manage they need to understand the process. The problem is that managers very often do not understand the software engineering field particularly well at all. I've seen it a thousand times that both large and small issues are simply ignored by managers, because they either do not understand them or even if they manage to grasp something, they fail to understand that they need to actively do something about it or just plain out ignore the issue, either with wishful thinking or just a power move where they think the issue isn't theirs to solve and in fact that the issue lies on the engineer to resolve. Most engineers are highly logical and would not bring something up without good reasons. It will have a negative impact if not handled.

I do not manage like this myself and I do not blame my engineers for anything that sits on my head, but I learned these lessons painstakingly through 15+ years of professional coding myself, seeing all kinds of roles at all kinds of companies creating chaos, project managers, product managers, bad managers, bad manager's managers, etc, but also the good ones luckily, the ones that were respected, knew what they were talking about, won the hearts of engineers, etc. This is what I modelled my own path after.

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

#50

Post by yeneek »

Author is wrong about the underlying cause of that disaster.

From my point of view, the cause is different:

1. Lack of design a.k.a. designed by coders > At 5 months the team has happy path coded the entire feature list, the screens are ugly and non-intuitive, ...

It's obvious, that the product wasn't designed. Feature list isn't design. Competitors app isn't design. When you have UX/UI/API designed, it doesn't happen that the result product is ugly because of the lack of time. Lack of time may cause, that there will be nicely looking, but slow/incomplete/unreliable product. You need blueprints before building. It can be designed upfront by one designer who is in contact with user and stakeholders. When not, it has to be designed during coding by software engineers which are drowning in technical details and cut off from users. So just having some more time wouldn't make it a good product.

Also with some plan, they could have created estimation based on something. That would help them to get a realistic timeline.

In the end, the boss and PM should have known better.

Post reply on HN