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)

#201

Post by ornornor » Sat, Aug 07, 2021, 10:13 PM UTC

darkerside wrote: post #199

ornornor wrote: post #198

Earlier quoted context omitted.

By refactoring, I mean cleaning it up once it works. But in my managers mind, as soon as the code works it’s good enough. Doing anything beyond that like sensible variable names, comments, making the code easier to read and follow is gold plating. So the second your hacked together development code works, you’re supposed to merge it and move on to the next ticket. The pipeline stuff is gold plating because it takes l…

You are free to approach this as you wish. Know that others have been there before, but most of the industry has moved on from where your organization is now. It wasn't done by digging in heels and expressing frustration, and it certainly wasn't done by giving up. The truth is, your manager's goals are probably more aligned with yours than either of your realize. Part of growing in your career is learning how to make…

Thanks! This business is doing well, it’s just entrenched in its ways, leadership is old and averse to change. I made my peace with the situation, I’m not interested in becoming a lead or anything and I’d rather save my energy for my life outside of work. I understand this doesn’t necessarily work for everyone, and I hope your replies will be useful to others in similar situation but with more desire than me to change things. Anyway, whatever works!

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

#202

Post by darkerside » Sun, Aug 08, 2021, 1:06 PM UTC

ornornor wrote: post #201

darkerside wrote: post #199

Earlier quoted context omitted.

You are free to approach this as you wish. Know that others have been there before, but most of the industry has moved on from where your organization is now. It wasn't done by digging in heels and expressing frustration, and it certainly wasn't done by giving up. The truth is, your manager's goals are probably more aligned with yours than either of your realize. Part of growing in your career is learning how to make…

Thanks! This business is doing well, it’s just entrenched in its ways, leadership is old and averse to change. I made my peace with the situation, I’m not interested in becoming a lead or anything and I’d rather save my energy for my life outside of work. I understand this doesn’t necessarily work for everyone, and I hope your replies will be useful to others in similar situation but with more desire than me to chang…

That's fair. I don't recommend complaining on the internet about it because it normalizes bad behavior that used to be normal but no longer is in functional organizations. There are lots of younger developers on here who don't know any better, and while we oldsters can stick it out until retirement, their careers will be much more fulfilling if they recognize the capacity to change their environments.

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

#203

Post by quickthrower2 » Sun, Aug 08, 2021, 1:39 PM UTC

wmeredith wrote: post #129

mprovost wrote: post #78

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

"In the eyes of those who anxiously seek perfection, a work is never truly completed—a word that for them has no sense—but abandoned ; and this abandonment, of the book to the fire or to the public, whether due to weariness or to a need to deliver it for publication, is a sort of accident, comparable to the letting-go of an idea that has become so tiring or annoying that one has lost all interest in it." –Rosalie Mag…

Is this why people have trouble with the last 5% of finishing their personal projects?

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

#204

Post by quickthrower2 » Sun, Aug 08, 2021, 1:43 PM UTC

ilaksh wrote: post #183

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…

You have to try to understand that building software is not like baking a cake in a custom shape. Which if you have seen those shows it requires a certain amount of ingenuity to create a cake shaped like a fountain. Or whatever. But fundamentally software development has 1000 to 1000000 more moving pieces than a cake, generally a research project, like building a new type of aircraft engine. Except, imagine it was a…

And you don’t really know if anyone wants an engine, although the word got banded about in some initial conversations. You could ask the customer but they want faster horses, and you are not allowed to talk to them anyway as you are assumed to not have stakeholder skills plus you are paid too much to not be coding.

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

#205

Post by quickthrower2 » Sun, Aug 08, 2021, 1:47 PM UTC

nonameiguess wrote: post #34

stephc_int13 wrote: post #18

There is a counter intuitive thing about software project estimation that took a long time for me to discover. The more rigorously you try to analyse the problem, cutting it into smaller and smaller parts, the more error you introduce, reducing the value of the estimate at each step. Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences. If you don't have…

Theoretically, this should be the exact opposite of the truth. Breaking a big prediction into a whole lot of smaller predictions is the basic intuition behind Fermi estimation and wisdom of crowds. As long as errors are symmetrically distributed and independent of each error, they'll cancel each other in aggregate. The problem is estimation errors are not symmetrically distributed because engineers chronically under…

It’s the breaking down that is challenging, because the breaking down is the work. The correct breakdown is known when the project is completed. Until then, there are only approximate and probably wrong breakdowns.

Ever had a task with 4 seemingly “easy” parts where 3 are easy and it turns out 4 requires a big rewrite because of some hacked put in 8 years ago that are now deeply ingrained assumptions in the code?

Often you are asked to estimate a 10k part project!

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

#206

Post by danparsonson » Mon, Aug 09, 2021, 1:54 PM UTC

ilaksh wrote: post #183

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…

You have to try to understand that building software is not like baking a cake in a custom shape. Which if you have seen those shows it requires a certain amount of ingenuity to create a cake shaped like a fountain. Or whatever. But fundamentally software development has 1000 to 1000000 more moving pieces than a cake, generally a research project, like building a new type of aircraft engine. Except, imagine it was a…

Sorry only just saw this.

I'm a software developer, have been for my whole career, so I know what building software is like. And while I agree that sometimes there are significant unknowns to resolve, and these can require large amounts of time, still the company has to market and prepare to sell the product before it's finished, otherwise as I said the company has to wait months or even years to get paying customers, by which time a) they'll have burned a huge amount of money without seeing any return and b) they may have missed their market opportunity. In the case of B2B transactions, the customer may have made significant operational decisions based on the deadline they've agreed to, and the supplier missing that deadline can have serious repercussions for a relationship that may have taken many years to build.

And come on, let's be honest - most of the time we're not designing a new type of aircraft engine. We're building something that looks very much like existing engines in general form, but with specifics that are different. I know it's hard, and I know estimates are a significant source of pain, but we need to have some sympathy for the rest of the company that's ultimately bringing in the piles of money that we get paid.

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

#207

Post by cpach » Sun, Aug 15, 2021, 3:24 PM UTC

ChrisMarshallNY wrote: post #117

moonchrome wrote: post #98

Earlier quoted context omitted.

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.

It’s a paraphrase, but the origin is indeed Aristotle.

http://www.universalethics.org/Ideas/Virtue_as_a_habit.htm

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

#208

Post by NeedsCoffee » Thu, Aug 19, 2021, 7:56 PM UTC

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…

Do you want developers that are passionate about their work or do you want compliant drones that will only ever do the bare minimum for you and blindly follow the directions laid out by management, even when they know it will be a disaster? I see a lot of companies where management just keep pushing their employees to get a month's work done in a few days, cutting corners and creating issues because nothing is properly thought out or tested.

It's called "development" not "Bam, it's done!" The best companies allow proper time for the development process to take place and have a proper team structure. Companies where everything is discussed as a team and you succeed and fail as a team. Proper agile teams which communicate at every step, with developers, testers, a scrum master, a business owner and a manager.

If you don't have that, you're basically not a proper development team, you're more of a startup that can't afford a proper development team. Nothing wrong with startups, but if you are a startup then you have to deal with your own weaknesses and shortcomings and take your failures on the chin.