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

191–200 of 208 posts

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

#191

Post by ornornor »

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…

> gold plate

At my current employer, managers love to use this term. We are asked not to gold plate.

And yet they’re the least qualified to decide what is gold plating.

Case in point, gold plating in my managers’ minds means: “code reviewing, refactoring, automating code quality (linting in pipeline etc), or writing any kind of test”. To the rest of us, this is far from gold plating, nice to have, or optional. Yet this is what gets cut every single time. And then we’re asked why we suck so much and “just fixing that one little button” takes a month and breaks five other things.

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

#192

Post by ornornor »

jdbernard wrote: post #99
nonameiguess wrote: post #41

Earlier quoted context omitted.

Also government contracts, at least in the US, have to be authorized by an appropriations bill from Congress. A federal agency can't just go to Congress and ask for an unknown amount of money to deliver a capability at an unknown date. Whether it ends up being right or not, and probably it usually isn't, appropriations bills have to be time-bounded and include a maximum dollar amount, and the awarded contract can't g…

In which case it would be wise to be extremely conservative in your estimation, taking initial engineering estimates and padding them further, not whittling them down. Because a baby takes nine months and can't be safely rushed out in six no matter the acts of congress, presidential edicts, and demands from the grand poobah. If you fix the dates, something else has to give. If time, cost, and scope are all fixed you'…

> I'm not saying you can't come in on time and under budget.

Isn’t this what we tell our managers to make them feel better about our estimates? I’ve never ever seen or heard of a software project being delivered on time and under budget.

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

#193

Post by ornornor »

timmg wrote: post #105

I always tell my PM: You can pick a feature set or a launch date. You can't pick both.

My team tried that too. We were laughed out of the room. The project failed. We’re starting a new project with exactly the same mindset. But this time it’s different, I’m sure.

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

#194

Post by BackBlast »

kitsune_ wrote: post #22
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…

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 think every case is individual. One of my recent gigs had management failures and engineering failures.

Management failed to communicate the limitations of the investment by investors to finish a project. In this case 4 months window of having an additional small team to build it. I had to pay very close attention to extract that information, my inquiries into it were rebuffed. My contract held the most clues.

Engineers didn't bother to listen to the clues and started a design by committee loop that was going to take a year+ to finish. They were much more interested in new shiney things than the financial business restrictions and this attitude was enabled by management.

We managed to finish something within the investment period only because I pushed and prodded at every turn trying to finalize decisions and cut out scope, without managements help, to do so. The manager who tried to shield engineering from deadlines didn't help this despite the train wreck I tried to communicate. At the end of the investment period all the extra engineering hired for the task were let go and the regulars were left to finish the demo we managed while maintaining their normal work load. It is now almost a year later it still isn't released.

While there are places where tone deaf management creates death matches for no good reason. There are apparently also places where management let's engineering walk all over them like a spoiled child with no grounding in financial realities.

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

#195

Post by darkerside »

ornornor wrote: post #191
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…

> gold plate At my current employer, managers love to use this term. We are asked not to gold plate. And yet they’re the least qualified to decide what is gold plating. Case in point, gold plating in my managers’ minds means: “code reviewing, refactoring, automating code quality (linting in pipeline etc), or writing any kind of test”. To the rest of us, this is far from gold plating, nice to have, or optional. Yet th…

Sounds like they need education on several of those points. Code review, and automated tests should be table stakes, not gold plating. Linting doesn't even seem to belong in that list because why would it add to development time?

Refactoring is a bit different in my mind. I often discover better ways to write a piece of functionality while I am writing it. Sometimes it's worth essentially starting over, and sometimes it's not. That decision IMO should be heavily influenced by business deadlines. There are times to push back the deadline because of a major refactor, but they damn well better be a rare exception, and you (and your manager) damn well better be able to explain the business reasoning behind it.

Lumping poorly judged refractors, last minute pet features, and optimizations (actual gold plating) in with critical technical practices like testing and review is probably part of the problem in your organization..

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

#196

Post by darkerside »

FinanceAnon wrote: post #184
darkerside wrote: post #181

Earlier quoted context omitted.

So developers should work on features until they get bored of making them better?

That's not what I am saying. The parent post makes it sound like, if a developer doesn't have a deadline he will just work on a single feature forever. I am saying that most developers intrinsically want to complete features to move on to new stuff. If they are in a good environment, arbitary deadlines are not required. When I pick up a feature, I know roughly how long it will take and I will try to finish it within…

> I know roughly how long it will take

You've formed your own arbitrary deadline right there, because what I was trying to say with my admittedly brief and snarky comment is that a feature being "done" is subjective.

You may have terrific business sense, and more importantly, one that is aligned with your stakeholders. That doesn't mean any other developer does. Agreeing on a deadline in many cases of a healthy team practice.

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

#197

Post by [deleted] »

ornornor wrote: post #191
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…

> gold plate At my current employer, managers love to use this term. We are asked not to gold plate. And yet they’re the least qualified to decide what is gold plating. Case in point, gold plating in my managers’ minds means: “code reviewing, refactoring, automating code quality (linting in pipeline etc), or writing any kind of test”. To the rest of us, this is far from gold plating, nice to have, or optional. Yet th…

[deleted]

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

#198

Post by ornornor »

darkerside wrote: post #195
ornornor wrote: post #191

Earlier quoted context omitted.

> gold plate At my current employer, managers love to use this term. We are asked not to gold plate. And yet they’re the least qualified to decide what is gold plating. Case in point, gold plating in my managers’ minds means: “code reviewing, refactoring, automating code quality (linting in pipeline etc), or writing any kind of test”. To the rest of us, this is far from gold plating, nice to have, or optional. Yet th…

Sounds like they need education on several of those points. Code review, and automated tests should be table stakes, not gold plating. Linting doesn't even seem to belong in that list because why would it add to development time? Refactoring is a bit different in my mind. I often discover better ways to write a piece of functionality while I am writing it. Sometimes it's worth essentially starting over, and sometimes…

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 longer than two minutes to configure and it then blocks merges and PRs when the code doesn’t pass linting etc (which slows us down right now, never mind that it’ll save a lot of time down the line)

I’m mostly just venting with like minded peers though. At that point, I’ve given up on fixing anything. I’ve tried, it burnt me out, and had no effect. Now I just put my 8h in, get my paycheck, and watch as we’re setting piles of money on fire. You can lead a horse to water etc.

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

#199

Post by darkerside »

ornornor wrote: post #198
darkerside wrote: post #195

Earlier quoted context omitted.

Sounds like they need education on several of those points. Code review, and automated tests should be table stakes, not gold plating. Linting doesn't even seem to belong in that list because why would it add to development time? Refactoring is a bit different in my mind. I often discover better ways to write a piece of functionality while I am writing it. Sometimes it's worth essentially starting over, and sometimes…

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 the connection for other people between these unintuitive things that make development faster and the goals they are trying to achieve. I wouldn't give up on finding new ways to share that understanding. It's called working on your leadership skills.

I'll caveat that there are some cases where it doesn't make sense to do the things you described. Maybe you're working on a prototype, or maybe the cash situation of the business is truly precarious. But if you want people to buy in on change, you need to understand their goals and relate to them on that level. Good luck!

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

#200

Post by FinanceAnon »

darkerside wrote: post #196
FinanceAnon wrote: post #184

Earlier quoted context omitted.

That's not what I am saying. The parent post makes it sound like, if a developer doesn't have a deadline he will just work on a single feature forever. I am saying that most developers intrinsically want to complete features to move on to new stuff. If they are in a good environment, arbitary deadlines are not required. When I pick up a feature, I know roughly how long it will take and I will try to finish it within…

> I know roughly how long it will take You've formed your own arbitrary deadline right there, because what I was trying to say with my admittedly brief and snarky comment is that a feature being "done" is subjective. You may have terrific business sense, and more importantly, one that is aligned with your stakeholders. That doesn't mean any other developer does. Agreeing on a deadline in many cases of a healthy team…

Arbitrary - based on random choice or personal whim, rather than any reason or system (first definition from google)

I think that reasonable and technically-informed deadlines are fine. But arbitrary deadlines are not a good long term approach.

We probably agree, but it's difficult to explain everything via comments :)

Post reply on HN