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

101–110 of 208 posts

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

#101

Post by dangerface »

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." you say "no" problem solved, until your line manager goes to the big boss who asks the same thing and do you know what your answer is? Thats right its "no". When the big boss says you have to do something then tell him "I cant magic more time you need to cut features", big boss and manager will argue their point but unless you can do magic your point remains the same.

I know its scary being blunt with your big boss but as a senior developer thats your job.

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

#102

Post by taneq »

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…

> users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it

This is true and, once you get over the myopic code focus that most of us shared in university, incredibly self-evident. "Users prefer to use the thing that solves their problem better than not using the thing." I mean... yes?

The real takeaway is that "software quality" means something very different to users than it does to developers. Developers want efficient, ergonomic libraries, aesthetically pleasing logical structures, and elegant software designs. That's what we call "quality". Users just want their damn problem solved, and if they can GET software like that which solves that problem, then you bet they'll buy it, but if they can't then anything which actually solves their problem is far better than doing it by hand.

This was the first big lesson I learned out of uni and it's stuck with me ever since. If you're interested in making commercial software, you're not there to solve the problems YOU think are important, you're there to solve the problems YOUR CUSTOMERS think are important.

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

#103

Post by vagrantJin »

To be fair, Engineers engineer and wouldn't mind spending twenty years engineering and discovering new paradigms and interesting things to get 1.2% gains. Deadlines force the issue to put the wandering mind of the engineer in a straight-ish path. Not perfect, but the alternative would take a lifetime.

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

#104

Post by grepfru_it »

ChrisMarshallNY wrote: post #93
grepfru_it wrote: post #91

Earlier quoted context omitted.

I hear you, but this problem becomes exponentially harder as your engineering org grows. I witness on a daily basis PRs that have no body getting merged with absolutely zero comments and a blanket approval as long as it passes our (broken) CI pipeline. I witness obvious poor quality in the code, but engineers want to seem like they are working and will just blanket approve PRs, while i'm in the middle of writing up m…

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.

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

#106

Post by stavros »

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…

> 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 months improving it (while people use it and I learn more about what they want) rather than take a year releasing a high-quality app nobody wants to use.

This assumes you aren't just building it for fun, though, in which case building it is the point, and you don't even need to release it afterwards.

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

#107

Post by jnwatson »

pjc50 wrote: post #30
danparsonson wrote: post #12

Alternate view point - driving projects to a specific deadline allows the other departments in the company to coordinate marketing, packaging, and selling the product. These people don't sit on their hands patiently waiting for engineers to finish building, their work can take many months just as the development does, and sometimes also involves making tradeoffs to deliver on time. No company wants to wait another ye…

Yeah, this is an unfortunate truth that Agile has to confront; there may be hard coordination deadlines. Or, in startups, a financial "runway". On the other hand, setting a deadline can't force something to be possible, it can only force people to work harder and more painfully towards it. I'm sure the Amazon drone delivery failure had a date target, for example. And there have been plenty of failed "big bang" IT mig…

Agile is fine with fixed due dates. Fixed features on the other hand...

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

#108

Post by Sparkyte »

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…

The magical scope creep fairy wants to talk to you. :)

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

#109

Post by phlakaton »

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…

I, too, am a firm subscriber to the Goodman Durnik school of development. With an occasional bring-a-flaming-sword-into-a-meeting-room-to-emphasize-your-point twist.

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

#110

Post by mwcampbell »

> The Big Boss is a pressure kind of guy, he believes that people work best when they are under pressure and if pressure isn't applied, they waste a lot of time on unnecessary things. [...] he goes away thinking what he already knew, that engineering is just screwing around instead of getting the project done.

Sadly, he's often not wrong. My own work ethic isn't exemplary, and sometimes in the absence of pressure I slack off. I'm surely not the only one. I don't know what to do about it though.

Post reply on HN