5 ms·

As an engineer, I've never personally understood the desire to release anyway, even when a system has known critical deficiencies like this one. Sure, perfect i

As an engineer, I've never personally understood the desire to release anyway, even when a system has known critical deficiencies like this one. Sure, perfect is the enemy of good, but I'd also argue that inoperable is the enemy of good - it only serves to erode trust in your product, if your team chose to release an unusable product. Some years ago, I worked on a system not quite as bad as what the author described, but close. We released a new product with a known, quite bad security vulnerability (I'd made sure our product team was _extremely_ aware of this), as well as no monitoring to speak of. The deadline had been communicated for around one year, but nobody had ever really discussed the significance of the date, other than it was what we were all death-marching to, and we needed to deliver. What did that date turn out to be? The head of product management's birthday, which was revealed to the rest of the company on the highly-celebrated the launch date. People were just kissing ass. I left several months later. It feels unconscionable to me that a company could have launched an incomplete, insecure, customer-facing product just to give a birthday gift to a leader, but I suspect this sort of thing is common.

nicbou 3y ago
> I've never personally understood the desire to release anyway I work alone with no deadlines. Sometimes I have to release something or I'll never finish. Perfect is the enemy of the good, as the saying goes. I often realise that half the "blockers" are actually nice-to-haves that I'm willing to complete much later. However I don't consider the thing finished, only released. In a dev team, the post-release bug-fixing and refactoring never takes place. Managers immediately move on.
Tomte 3y ago
I used to work in a company where important dates (inauguration of new development building, important product release etc.) were set to the birthday of the owner/CEO's late husband. Come what may. If your product was to be released somewhere in that half of the year, this date it was.
- geosh 3y ago
  It's like a communist party opens a dam or a factory earlier just because it's the party's anniversary.
marcus_holmes 3y ago
There's a whole management philosophy around deadlines; that setting a hard deadline will make the project predictable. For non-engineering projects this is often true. For engineering projects not so much. Non-technical managers have a hard time with software engineering projects because they're opaque and unpredictable. Opaque in the sense that no matter how many progress reports they get, the manager will never understand what progress is actually being made (because they can't read the code). And unpredictable because development is inherently unpredictable. By setting a hard deadline managers seek to control the project. Engineers will come to them with "we can't release this by the deadline because $technical_gibberish". But the temptation is always to just stick to the deadline and refuse to extend it, because once you extend it once then everyone knows it isn't actually a hard deadline and the deadline will get extended again and the thing will never get released. My worst case was one project where the management team decided that we could skip the testing phase and just test on prod after launch, because that would allow us to meet the deadline. Obviously the application completely failed because there were thousands of bugs in it that hadn't been caught. The post-mortem was a total blamefest. The project got canned and people got fired. All that effort for nothing, just because they wouldn't extend by a few weeks. But we met the deadline!
- el_oni 3y ago
  I work better when I have a deadline, but i also expect my manager to allow for slippage if something is wrong with the product. Currently we have an issue where we are telling the customer that we need a 4 week pilot to make sure that when real data comes in it behaves as we expect, and so we can get back to providers on how to fix their data. If you go live with only synthetic data ever going through your product then you are asking for trouble. They are trying to negotiate that down to 2 weeks. Why? so their KPIs are met? Maybe it's because we are external, and if it fails they can blame us for the problem rather than them nickle and diming over a couple of weeks. I want to consult in a different sector after this :/
- sjamaan 3y ago
  > But the temptation is always to just stick to the deadline and refuse to extend it, because once you extend it once then everyone knows it isn't actually a hard deadline and the deadline will get extended again and the thing will never get released. Personally, I've seen so many "super duper important must-meet" deadlines which in the end turned out to be completely unimportant, that I've decided long ago that I'm not gonna do any more overtime to make any deadlines. It's quite a sobering experience as a developer to stress over making a heroic effort to meet a deadline only to see after the deadline passed that actually it wasn't really so make or break after all, and that there was plenty of time to fix the issues afterwards. It's really not worth it to abuse your body and your mind by working overtime and spending too much time in a bad posture behind a computer just to make someone else happy. Of course, I'll still do my best (I always do), and I might even agree to moderate amounts of overtime where it's warranted (as in: not because it is necessary because of shitty planning), but I'm not putting any emotional energy into deadlines, ever again.

nicbou 3y ago

> I've never personally understood the desire to release anyway I work alone with no deadlines. Sometimes I have to release something or I'll never finish. Perfect is the enemy of the good, as the saying goes. I often realise that half the "blockers" are actually nice-to-haves that I'm willing to complete much later. However I don't consider the thing finished, only released. In a dev team, the post-release bug-fixing and refactoring never takes place. Managers immediately move on.

Tomte 3y ago

I used to work in a company where important dates (inauguration of new development building, important product release etc.) were set to the birthday of the owner/CEO's late husband. Come what may. If your product was to be released somewhere in that half of the year, this date it was.

geosh 3y ago
It's like a communist party opens a dam or a factory earlier just because it's the party's anniversary.

marcus_holmes 3y ago

There's a whole management philosophy around deadlines; that setting a hard deadline will make the project predictable. For non-engineering projects this is often true. For engineering projects not so much. Non-technical managers have a hard time with software engineering projects because they're opaque and unpredictable. Opaque in the sense that no matter how many progress reports they get, the manager will never understand what progress is actually being made (because they can't read the code). And unpredictable because development is inherently unpredictable. By setting a hard deadline managers seek to control the project. Engineers will come to them with "we can't release this by the deadline because $technical_gibberish". But the temptation is always to just stick to the deadline and refuse to extend it, because once you extend it once then everyone knows it isn't actually a hard deadline and the deadline will get extended again and the thing will never get released. My worst case was one project where the management team decided that we could skip the testing phase and just test on prod after launch, because that would allow us to meet the deadline. Obviously the application completely failed because there were thousands of bugs in it that hadn't been caught. The post-mortem was a total blamefest. The project got canned and people got fired. All that effort for nothing, just because they wouldn't extend by a few weeks. But we met the deadline!

el_oni 3y ago
I work better when I have a deadline, but i also expect my manager to allow for slippage if something is wrong with the product. Currently we have an issue where we are telling the customer that we need a 4 week pilot to make sure that when real data comes in it behaves as we expect, and so we can get back to providers on how to fix their data. If you go live with only synthetic data ever going through your product then you are asking for trouble. They are trying to negotiate that down to 2 weeks. Why? so their KPIs are met? Maybe it's because we are external, and if it fails they can blame us for the problem rather than them nickle and diming over a couple of weeks. I want to consult in a different sector after this :/
sjamaan 3y ago
> But the temptation is always to just stick to the deadline and refuse to extend it, because once you extend it once then everyone knows it isn't actually a hard deadline and the deadline will get extended again and the thing will never get released. Personally, I've seen so many "super duper important must-meet" deadlines which in the end turned out to be completely unimportant, that I've decided long ago that I'm not gonna do any more overtime to make any deadlines. It's quite a sobering experience as a developer to stress over making a heroic effort to meet a deadline only to see after the deadline passed that actually it wasn't really so make or break after all, and that there was plenty of time to fix the issues afterwards. It's really not worth it to abuse your body and your mind by working overtime and spending too much time in a bad posture behind a computer just to make someone else happy. Of course, I'll still do my best (I always do), and I might even agree to moderate amounts of overtime where it's warranted (as in: not because it is necessary because of shitty planning), but I'm not putting any emotional energy into deadlines, ever again.