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

181–190 of 208 posts

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

#181

Post by darkerside »

FinanceAnon wrote: post #111
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?

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

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

#182

Post by ilaksh »

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 issue is that many people are in a situation where the manager will either decide to just not listen and promise those dates or features anyway or they will be demoted,.fired or otherwise penalized for not going along with it.

That's a problem because many people do not have the luxury of quitting for another job easily.

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

#183

Post by ilaksh »

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 really new type of engine that was being built based on an alien landing. But they could not get into the engine to see how it worked because it was an unknown alloy. So they were trying to invent a new type of anti-gravity drive based on a few clues.

I mean we are not trying to defy gravity, but there a shitton of unknown unsolved problems. You can't promise or create marketing for a feature unless we already know it's possible. For starters.

But the issue is worse than that. What generally happens is once one part of the new engine is barely working, they demand another new invention that has to be completes in the same deadline before the other one has corner cases examined even.

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

#184

Post by FinanceAnon »

darkerside wrote: post #181
FinanceAnon wrote: post #111

Earlier quoted context omitted.

>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?

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 that time. I don't need an arbitary deadline from management.

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

#185

Post by taneq »

liketochill wrote: post #163
taneq wrote: post #141

Earlier quoted context omitted.

> It seems strange to me that software engineers are so frequently singled out for schedule slippage It follows this trend I've seen across the board in business throughout my career, of mistaking the last hair on the last yak for the entire job. The classic example is documentation. "Hey the electrical drawings are due on Thursday the Aprilteenth, can you have them ready by then?" Oh sure, that's two months away, th…

I’m also in industrial automation and know the challenges of being “last” in years long projects. We are very deliberate about setting deliverable dates in time after the required inputs by others are available, and when inevitably they are not, we have a spreadsheet sent to the customer every 2 weeks which shows what information we are missing and the delay that is causing to our progress. As we are liable for damag…

> We are very deliberate about setting deliverable dates in time after the required inputs by others are available, and when inevitably they are not, we have a spreadsheet sent to the customer every 2 weeks which shows what information we are missing and the delay that is causing to our progress.

This is a great approach if you can stay that organised. It reminds me of one of my fundamental rules of business - the two benchmarks you're compared to are the previous entry in the Gantt chart and your counterpart in the client organisation. If you can stay ahead of both of those, you're golden!

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

#186

Post by gkrimer »

grepfru_it wrote: post #91
ChrisMarshallNY wrote: post #86

Earlier quoted context omitted.

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

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…

Please come work at Google! This place has the best overall code quality I have ever seen. That's not to say it's always great or bug-free, but it is almost always well maintained. There is very little dead code. Giving and receiving high-quality code reviews is the norm.

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

#187

Post by ChrisMarshallNY »

gkrimer wrote: post #186
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…

Please come work at Google! This place has the best overall code quality I have ever seen. That's not to say it's always great or bug-free, but it is almost always well maintained. There is very little dead code. Giving and receiving high-quality code reviews is the norm.

That’s one company that would almost certainly not have me, but I very much appreciate the thought.

Apple also displays extremely high quality code, in the areas that are exposed to the public.

I have not seen too much Adobe code, but I’m told you can eat off the Photoshop codebase.

For myself, I need to keep my scope fairly humble, but I get great joy from it.

It sounds like a gratifying environment. Good show!

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

#188

Post by grepfru_it »

gkrimer wrote: post #186
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…

Please come work at Google! This place has the best overall code quality I have ever seen. That's not to say it's always great or bug-free, but it is almost always well maintained. There is very little dead code. Giving and receiving high-quality code reviews is the norm.

Hey, I found your email on another thread.. I will reach out!

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

#189

Post by c_o_n_v_e_x »

liketochill wrote: post #163
taneq wrote: post #141

Earlier quoted context omitted.

> It seems strange to me that software engineers are so frequently singled out for schedule slippage It follows this trend I've seen across the board in business throughout my career, of mistaking the last hair on the last yak for the entire job. The classic example is documentation. "Hey the electrical drawings are due on Thursday the Aprilteenth, can you have them ready by then?" Oh sure, that's two months away, th…

I’m also in industrial automation and know the challenges of being “last” in years long projects. We are very deliberate about setting deliverable dates in time after the required inputs by others are available, and when inevitably they are not, we have a spreadsheet sent to the customer every 2 weeks which shows what information we are missing and the delay that is causing to our progress. As we are liable for damag…

I "grew up" in industrial automation, I feel ya on delays. I relocated overseas for DCS project on a new chemical plant. The planned length of the assignment was 14 months...4.5 years later, we were finished. One EPC was not able to get the underground utilities installed in time before other EPCs (there were 4) started moving in pipe racks, equipment modules, etc. Imagine trying to put in all your underground cables, sewers, pipes, etc. after the site had already been built on top.

Another EPC was moving so fast to try and meet a project milestone in order to get paid, they installed an instrument enclosure totally backwards (huge crane required to drop enclosure into place). They still got paid as the milestone didn't specify the enclosure had to be installed correctly.

One of annoying aspects about controls is that non-technical stakeholders see a mechanically complete object/machine/plant and wonder why it isn't working yet. Also, I always found that the controls guys were the first to get yelled at if something at site stopped working.

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

#190

Post by branko_d »

datalus wrote: post #100
tkiolp4 wrote: post #83

Earlier quoted context omitted.

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 would say a lot of this confusion comes from the word engineer. Building software is not like building a bridge. You can't design it first and then go and build it. So I would say engineer is a poor term, but also the only one we've got for now.

It's exactly like building a bridge... if nobody never built a bridge before.

The only reason you can design a bridge beforehand is because (millions?) bridges have been built before so you can apply the lessons learned. Even if your bridge is "unusual", it will still be similar enough to older bridges so you don't have to invent the vast majority from scratch.

Other kinds of engineering don't have the luxory of leaning on the prior experience so much, simply because there is less of it. SpaceX's reusable rocket could not have been be fully designed before built, simply because nobody built a reusable rocket before. But it could be done through iteration, which is just another name for experimentation.

Software tends to be less like bridges and more like rockets... all of which falls within the spectrum of "engineering".

Post reply on HN