Live data from Hacker News

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

iism.org

81–90 of 208 posts

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

#81
post #56

Earlier quoted context omitted.

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

I guess it depends how you look at it, but regarding my point it isn’t. For example most ecom apps/sites are surely ”unique” based on how you described it, but customers have nearly unlimited options/alternatives these days.

I was referring to enterprise internal or b2b software

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

#82
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 us…

Professional developers should strive to write the highest quality code they can given the constraints of the project. That's pretty much a given. I'm only arguing that customers don't seem to care, not that we shouldn't care.

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

#83
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 us…

You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high-quality and useful products), almost everyone hates software engineering.

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

#85
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…

This is true, although there are other aspects. For example, if the best available solution to a problem is using software I hate then I'm going to develop a resentment towards its developers and consider them last when trying to solve future problems.

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

#86
post #83

Earlier quoted context omitted.

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 us…

You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…

Yes, I've been writing it alone, but my "alone" work is at a different level, from what many folks do. Approaching every bit of work I do as "ship," is one of my oddities. I have as much fun, shipping, as I do writing.

I consider everything I do, "engineering." Been doing that, all my adult life.

Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a number of its components are. It's still "under wraps."

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

#87
post #83

Earlier quoted context omitted.

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 us…

You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…

I don't like this definition of Software Engineering that necessitates a team of Other People. Perhaps I'm outright wrong that such a definition just shouldn't be. Even in that case, I just don't like it. :)

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

#88
post #23

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

So, projects fail because of (arrogant or inexperienced) developers but not because of managers. And then you wonder why engineers say “many managers do not know what they are doing”.

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

#89
There are three kinds of deadlines: fake deadlines, contract/revenue driven deadlines and reality driven deadlines. Most problems with deadlines I've seen come from chronically mislabeling the deadline (e.g. sales don't close, so engineers start ignoring revenue driven deadlines). Fake deadlines sometimes are necessary to get things to some finished state, but they should be used very sparingly. Deadlines should be honest, and when something changes (e.g. some other team is going to be 3 weeks late on their part of the product so being on time doesn't matter) the deadlines should be quickly adjusted. Deadlines are a work-planning and asset allocation constraint, and will cause very bad decisions if they are not understood and managed well.

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

#90
post #82

Earlier quoted context omitted.

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 us…

Professional developers should strive to write the highest quality code they can given the constraints of the project. That's pretty much a given. I'm only arguing that customers don't seem to care, not that we shouldn't care.

Exactly.

I read a book, where one of the characters is a smith. It has this exchange, between him, and another character:

    "Always do the very best job you can," he said on another occasion as he put a last few finishing touches with a file on the metal parts of a wagon tongue he was repairing.
    "But that piece goes underneath," Garion said. "No one will ever see it."
    "But I know it's there," Durnik said, still smoothing the metal. "If it isn't done as well as I can do it, I'll be ashamed every time I see this wagon go by -and I'll see the wagon every day.”
Post reply on HN