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

71–80 of 208 posts

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

#71

Post by hef19898 »

pjc50 wrote: post #45
andruby wrote: post #31

Earlier quoted context omitted.

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.

For Enterprise software I take auditable, stable processes and performance over a polished UI every single time. Also talking as a long time user of the poster child, SAP. Enterprise software doesn't have to be pretty, it has to do its job. And that requires a lot effort, I'd argue more effort than developing a polished consumer facing app.

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

#72

Post by Retric »

dagw wrote: post #65
Retric wrote: post #64

Earlier quoted context omitted.

The first mover advantage is an illusion. Google didn’t invent search or online Email. Microsoft didn’t pioneer personal computing, spreadsheets, or word processing. Facebook wasn’t the first social network. Apple made most of it’s money from markets it entered late iPod, iPhone, and then iPad where the Newton failed. Intel wasn’t the first to build a microprocessor. IBM didn’t invent the computer.

The first mover advantage is an illusion. I wouldn't go that far. All the cases you cite are of products that definitely classify as substantially better than what they replaced. Before Gmail took over the market from Hotmail there had been several other companies that failed due to only being slightly better. Yes you can beat the "first mover", but doing so is hard and requires an almost revolutionizing better produ…

I am not saying it’s easy to beat them, rather first movers also generally die or move on. Atari, Electronic Controls Company, Mosaic, etc simply aren’t around any more. Sure Yahoo isn’t dead, but it’s also moved on from it’s initial success.

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

#73

Post by long_time_gone »

righttoolforjob wrote: post #49
gregjor wrote: post #38

Earlier quoted context omitted.

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, the…

I’m confused about why software engineers think these things only apply to them. What makes that field so much more special than the accountants, finance analysts, marketing managers, and support reps? These people all get deadlines and have managers who “don’t understand what they do.”

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

#74

Post by indigochill »

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.

Even then, it's not what's important. The core important thing in the product is that it does a job the customer needs done. If you write a program that provides complete feature parity with the incumbent with better engineering principles, you're going to lose because the engineering principles aren't the job the customer needs done.

Where it will make the difference is that your company will be able to respond to changing requirements better than the incumbent.

So solid software engineering is never the product for the customer. It might be the product for the company, depending if the company actually needs the improved developer efficiency and happiness it provides.

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

#75

Post by bishoprook2 »

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

Another. Industries that are oriented towards tradeshow or holiday launches. It ain't like they're going to move NAB or Christmas just for you. Inevitable feature pruning occurs.

Having said that, I wonder how many of the great fortunes have been built on horrid, half-finished websites and associated software that were all about being first out of the gate and heavy marketing.

An interesting subcase is software that is difficult or impossible to update vs. immovable deadlines. I guess in a world that consists entirely of one silly internet surveillance marketing company after another is doesn't really matter much anymore.

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

#76

Post by mobjack »

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…

I often see engineers having a cynical self defeating view of the business. They will blindly follow complex requirements while complaining that there is not much they can do about it.

But if you demonstrate that you understand things from the business perspective, they are much more receptive to making adjustments.

Product managers like to gold plate things as much as engineers. There is usually some fat you can trim from the scope to make a deadline.

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

#77

Post by ChrisMarshallNY »

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…

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 user (even "good" surprises can be an issue. Boring software can be just what the doctor ordered).

In my book, that's the definition of "quality."

I'm working on an application that has been over a year in the making. Its functionality is something that I could have popped out in a month, but making sure of the Quality of the app has necessitated that I spend a great deal more time, "polishing the fenders."

If this were a commercial app (it isn't), then it would have been unbearably expensive for a startup.

I tend to write test harnesses in a day or two, that have similar levels of functionality to this application.

High Quality is significantly more expensive than even "decent, but lesser" quality.

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

#78

Post by mprovost »

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 something new. Then if the new stuff didn't work or was taking too long, you could always fall back to the old way. Which wouldn't look as good or achieve the effect you wanted, but :shrug:. There was always the chance that you'd work sometimes for years though and your work would get dropped which was never that fun for the artists involved. Most development teams don't have the resources to have an A and B team working on the same problem but it's a way to contain risk.

The studios use release dates as deadlines basically to contain costs. Otherwise some directors will just keep working on a movie forever (or keep going back to it like George Lucas). Some movies, especially with VFX, are never really done, they just get to the deadline and finish with what they have at that point.

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

#79

Post by dagw »

Retric wrote: post #72
dagw wrote: post #65

Earlier quoted context omitted.

The first mover advantage is an illusion. I wouldn't go that far. All the cases you cite are of products that definitely classify as substantially better than what they replaced. Before Gmail took over the market from Hotmail there had been several other companies that failed due to only being slightly better. Yes you can beat the "first mover", but doing so is hard and requires an almost revolutionizing better produ…

I am not saying it’s easy to beat them, rather first movers also generally die or move on. Atari, Electronic Controls Company, Mosaic, etc simply aren’t around any more. Sure Yahoo isn’t dead, but it’s also moved on from it’s initial success.

first movers also generally die or move on.

Sure, but before that they generally make a lot more money than the second and third mover. When all is said and done, Atari and Yahoo did much better than Colecovision and Lycos.

The risk with being the first mover is that, having easily seen off competition from the second and third mover, you become complacent and stop moving.

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

#80

Post by danparsonson »

Forge36 wrote: post #55
thow-01187 wrote: post #53

Earlier quoted context omitted.

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.

They are communicated to engineers - in the form of deadlines...
Post reply on HN