Driving engineers to an arbitrary date is a value destroying mistake (2020) • Hacker News Board

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

#111

Post by FinanceAnon » Fri, Aug 06, 2021, 2:05 PM UTC

darkerside wrote: post #26

I'm not convinced an arbitrary date is a bad idea, and in fact, I continue to think it's a good one. If you don't have a point in time you are optimizing for as a developer, then why wouldn't you continue to gold plate and improve your code? Once you have a ship date, you know when it is time to knock it off and start heading downhill. The real problem here is the leadership deficit. The manager got pushback on the e…

>If you don't have a point in time you are optimizing for as a developer, then why wouldn't you continue to gold plate and improve your code?

Because it feels good to complete work and I would like to move on to other features. How long can you work on improving a single piece of code before getting bored?

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

#112

Post by ChrisMarshallNY » Fri, Aug 06, 2021, 2:06 PM UTC

grepfru_it wrote: post #104

ChrisMarshallNY wrote: post #93

Earlier quoted context omitted.

Yeah. It can be a real challenge, ensuring quality on a team. The obvious answer, is to hire experienced, skilled, capable engineers, and instill in them, the same reverence for Quality that you have. Like I said, Quality is expensive. Very few companies like to pay the premium.

This does not work at scale. My company does pay the premium and a lot more.

It does, but it ain't easy. I worked for a company that did it at scale.

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

#113

Post by ChrisMarshallNY » Fri, Aug 06, 2021, 2:11 PM UTC

stavros wrote: post #106

ChrisMarshallNY wrote: post #77

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…

> 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." What happens if you release it and it turns out that nobody likes it? I'd have preferred to spend a month releasing a lower-quality app, and then spent 11…

You are correct, and that's the classic rationale for "MVP."

But I also follow a development methodology that I call "paving the bare spots."[0] It adjusts the design, as the project progresses. Not for the faint of heart. It means that I may toss out a month's work, because it does not fit the user experience (which is under constant revision). We have also made a couple of major pivots, during the project, to fit new realities.

I have probably tossed out three months' worth of work, as the project has progressed. Happy to do so. The best code, is the code I don't write.

The nice thing is, is that the product is constantly at "ship" Quality. Makes demos, user testing, and begging for money, easier.

[0] https://littlegreenviper.com/miscellany/the-road-most-travel...

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

#114

Post by Joeri » Fri, Aug 06, 2021, 2:12 PM UTC

occz wrote: post #96

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…

I like what Peopleware says on the matter - the market has squarely selected low quality software over high quality, but if you try to drive your teams to build low quality software you will lose because you will be unable to retain good developers.

Well, the market does not select for low quality, it just selects for an attribute that often coincides with low quality, like time to market or low cost.

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

#115

Post by bcrl » Fri, Aug 06, 2021, 2:15 PM UTC

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…

I think there's a difference between companies that build software for the market versus those that build software for a contract. The former tends to be driven by a team that believes in the product that they're trying to deliver, has a management team that has at least some vision for the software and investors that believe in the company's approach to the market. They want to make software / a product that represents the organization well and has long term value.

In the latter case, like so many government sponsored engineering projects, the company has no real long term incentive beyond what is written into the contract. Management isn't driven by the software being produced so much as meeting the contractual requirements that result in payments. In my experience, software contracting houses are a lot more likely to hold schedules over the heads of developers, and that's purely driven by the terms of the contract (billable hours). In contrast, even when I have been a contractor for a company that is building the product for itself, they tend to push for the goals of the project while ensuring it meets the needs of the company. The difference in pressure as a developer is quite substantial.

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

#116

Post by hobs » Fri, Aug 06, 2021, 2:18 PM UTC

narag wrote: post #48

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…

Android apps dont solve problems better than anything else, they are just more available so this doesn't gel for me.

Windows and Android keep reinventing the same wheel even though (especially Windows) is basically still in "Windows 95" mode - getting fancy with a phone ui is just trash.

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

#117

Post by ChrisMarshallNY » Fri, Aug 06, 2021, 2:18 PM UTC

moonchrome wrote: post #98

ChrisMarshallNY wrote: post #90

Earlier quoted context omitted.

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

One reason I like this kind of work is that it implies when someone spent that much effort on an irrelevant detail they probably paid attention to important parts as well. Not always the case but yeah.

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

- [Probably erroneously] ascribed to Aristotle

But naysayers will say we are "bikeshedding."

Meh. Whatevs. I do things the way I do.

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

#118

Post by umvi » Fri, Aug 06, 2021, 2:20 PM UTC

ChrisMarshallNY wrote: post #77

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

It's easy to make high quality software as a team of one - you never have to compromise, after all. You are basically a god of the project. When working on a large team though you have to make all sorts of trade offs at all sorts of levels and it's way harder to produce high quality software because you are no longer a god that controls every single aspect of the project.

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

#119

Post by hobs » Fri, Aug 06, 2021, 2:20 PM UTC

dangerface wrote: post #101

There is nothing wrong with working to dead lines estimating and planing development and releasing software thats good enough not perfect. The problem is when people start trying to change the plan half way through execution, non tech people will constantly try to do this because they are clueless its the project leads job to tell them no. When your manager asks you "if anything can be done to pull those dates in." y…

Ah, you are one of those "difficult developers" :) Be blunt with your boss but also dont forget to quit if they dont change their behaviors.

Just "finishing up" a project of "6 months" where we went from reasonable to unreasonable scope, and I was the only one that said it was unlikely we were going to finish on time, weird that I was the only non-contractor....

Almost a year a shoddy version that's just copying data from their existing product is only mostly a buggy mess!

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

#120

Post by mananaysiempre » Fri, Aug 06, 2021, 2:21 PM UTC

ChrisMarshallNY wrote: post #90

onion2k wrote: post #82

Earlier quoted context omitted.

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

  In the elder days of Art,
    Builders wrought with greatest care
  Each minute and unseen part;
    For the Gods see everywhere.

(from Longfellow, The Builders, 1850)

I’m not sure to which extent I agree with this piece’s medieval outlook of seeking and expecting perfection in the past, not in the future, but it doesn’t detract from the quality of this piece of writing. (Same for Tolkien, for example.) (And the poem actually talks about improving on the past, not venerating it; citing this part in isolation is a bit misleading.) (Now that I’m comparing these two quotes, the difference between “because the gods will see” and “because you’ll know it’s there” is... probably not worth overanalyzing, but at the same time intensely amusing.)