8 ms·

There's a whole management philosophy around deadlines; that setting a hard deadline will make the project predictable. For non-engineering projects this is oft

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.
- marcus_holmes 3y ago
  Last time I did, we got the product shipped by the deadline. Only to find the marketing team had messed up their Google account and couldn't do any of the planned launch advertising or tracking. Took them two weeks to sort that out. No hint of an apology or any of the fireworks that would have happened if we'd been two weeks late delivering the product. So yeah, I'm with you. Never again.
phkahler 3y ago
>> But we met the deadline! Bo. No they did not. The goal was to deliver a working product by some date. They missed the "working" part of that.
nvm0n2 3y ago
Whole industries get wrecked by this dynamic. I heard a story once about a well known bank. They tried to develop a new customer facing e-banking system (or was it a trading system, customer facing anyway). They started by outsourcing it to Thoughtworks, a consultancy, and those guys pushed for an agile methodology. They wanted regular feedback, iterations, etc and a contract that was essentially "keep paying us until you're happy and reach product acceptance". Non-technical management thought this sounded insane. They wanted something more like: you tell us how much it will cost and the exact day it will be complete, we pay you, it's done by that day and any delays trigger compensation. So they fired Thoughtworks and outsourced it to India. India delivers on a fixed price contract, on time. The bank are happy. Launch day gets near. They begin loading customer data into the live system in preparation. At first things are OK but then it starts slowing down. Slower and slower. By 100+ customers the system has slowed to a crawl. Investigation shows ORM abuse to be the root cause. There's no quick fix: the developers didn't understand ORMs or data model design and the whole codebase is just FUBARd performance wise. The project has to be completely written off. In the wake of this, said large bank becomes terrified of technology projects. They no longer want anything to do with them. They decide to buy a platform from a competitor and rebrand it. Internal execs warn that this strategy is suicidal as it ensure they can never differentiate, but the warnings go unheeded. It apparently took over a decade for the organization to recover its confidence enough to try software projects again. You see this everywhere outside the tech sector. Non-techs can't abide technical people and the way we do things. It's low key culture war. They see tech people as weird and unreasonable (sometimes true, but not moreso than the other way around). Nerds like Star Trek and get passionate about their tools and board games and the right way to interview people, and many other things that non-tech people find baffling or sometimes outright offensive (especially hiring). Non-tech can't tell the difference between BS and not, so constantly fall for yes men and grifters who just tell them what they want to hear. Then projects randomly explode and nobody can understand why or how to stop it happening again. One thing they will not countenance under any circumstances: learning enough tech to be able to manage technical projects. If it's ever brought up the idea will be laughed off. Programmers will learn banking/logistics/medicine/tax law/etc if necessary to understand a project, but the reverse is not true and frankly deep down that seems to scare them. These days most non-tech orgs have given up in my experience. They just want to buy a SaaS and if it means they can't differentiate from their competitors, oh well, too bad so sad but unless a tech startup takes an interest in your line of business it's not like any of your competitors are going to do it better.

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.

marcus_holmes 3y ago
Last time I did, we got the product shipped by the deadline. Only to find the marketing team had messed up their Google account and couldn't do any of the planned launch advertising or tracking. Took them two weeks to sort that out. No hint of an apology or any of the fireworks that would have happened if we'd been two weeks late delivering the product. So yeah, I'm with you. Never again.

phkahler 3y ago

>> But we met the deadline! Bo. No they did not. The goal was to deliver a working product by some date. They missed the "working" part of that.

nvm0n2 3y ago

Whole industries get wrecked by this dynamic. I heard a story once about a well known bank. They tried to develop a new customer facing e-banking system (or was it a trading system, customer facing anyway). They started by outsourcing it to Thoughtworks, a consultancy, and those guys pushed for an agile methodology. They wanted regular feedback, iterations, etc and a contract that was essentially "keep paying us until you're happy and reach product acceptance". Non-technical management thought this sounded insane. They wanted something more like: you tell us how much it will cost and the exact day it will be complete, we pay you, it's done by that day and any delays trigger compensation. So they fired Thoughtworks and outsourced it to India. India delivers on a fixed price contract, on time. The bank are happy. Launch day gets near. They begin loading customer data into the live system in preparation. At first things are OK but then it starts slowing down. Slower and slower. By 100+ customers the system has slowed to a crawl. Investigation shows ORM abuse to be the root cause. There's no quick fix: the developers didn't understand ORMs or data model design and the whole codebase is just FUBARd performance wise. The project has to be completely written off. In the wake of this, said large bank becomes terrified of technology projects. They no longer want anything to do with them. They decide to buy a platform from a competitor and rebrand it. Internal execs warn that this strategy is suicidal as it ensure they can never differentiate, but the warnings go unheeded. It apparently took over a decade for the organization to recover its confidence enough to try software projects again. You see this everywhere outside the tech sector. Non-techs can't abide technical people and the way we do things. It's low key culture war. They see tech people as weird and unreasonable (sometimes true, but not moreso than the other way around). Nerds like Star Trek and get passionate about their tools and board games and the right way to interview people, and many other things that non-tech people find baffling or sometimes outright offensive (especially hiring). Non-tech can't tell the difference between BS and not, so constantly fall for yes men and grifters who just tell them what they want to hear. Then projects randomly explode and nobody can understand why or how to stop it happening again. One thing they will not countenance under any circumstances: learning enough tech to be able to manage technical projects. If it's ever brought up the idea will be laughed off. Programmers will learn banking/logistics/medicine/tax law/etc if necessary to understand a project, but the reverse is not true and frankly deep down that seems to scare them. These days most non-tech orgs have given up in my experience. They just want to buy a SaaS and if it means they can't differentiate from their competitors, oh well, too bad so sad but unless a tech startup takes an interest in your line of business it's not like any of your competitors are going to do it better.