Reading HN comments makes it sound like engineers think they're the only ones in a company who have to deal with deadlines. It's kind of hilarious. Go ask your sales team how they cope with hard deadlines of closing a specific dollar amount every quarter based on the presupposition that 1. the product delivers what it says without major issues, 2. competitors don't come out with feature or pricing changes that blindside you, 3. other departments (marketing) delivering them enough interested contacts to talk to... and 100 other things. Not to mention the main "stakeholder" in play for them -- the customer -- is ACTIVELY trying to deceive the salesperson in order to get the best deal for themselves. Like, they will literally lie and say they intend to sign a contract with you by end of quarter to get the salesperson to go the extra mile for them. With zero intention of actually following through... Yet the sales team gets it done every quarter. And if they don't? 2 bad quarters in a row = expectation is you're out of a job.
I don't think the main point being made is that deadlines are a PITA, I think it's that the trade-off is unmeasured. Successfully meeting a sales deadline looks the same as signing the same contract after the deadline (other than the deadline), but the argument for deadlines in software being bad is that they materially erode quality and long term viability (shortcuts, tech debt, bugs, usability). The product delivered within the deadline is materially worse than the one delivered after. The problem is that it's hard to attribute these issues to "deadlines" although the intuition is that they are a major cause.
> Successfully meeting a sales deadline looks the same as signing the same contract after the deadline (other than the deadline)
This is so far from the truth. I encourage you to spend more time with your sales team and even your stakeholders who are buying $100k+ software from vendors. There are so many parameters of a deal that go beyond contract signature date. Deliverables, SLAs, roadmap commitments, length of contract, legal definitions, opt-out conditions, payment terms, pricing, and more. Deals aren't just "on time" or not, they vary greatly in terms of quality. And that quality largely determines your company's ability to hire more engineers. Or fire them. ;-)
Bad deals happen when you're down to the wire and have to get it done on time or people will lose their jobs. Not unlike bad software. Work in the real world has deadlines. The people doing the work will always advocate for the loosest deadlines (or none at all, as is often the case with engineers). The people who need the work done will always advocate for the fastest turnaround. Without these checks and balances, the work just does not get done fast enough or well enough to stay competitive.
