Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.
This. Most engineers delude themselves and plan for the happy path.
I was famous too for "being negative." In the planning of a complex project once a rather dull engineer, after I had just pointed out a major potential problem asked, "Why are you so negative?"
I've seen a lot of engineers be negative in a destructive way. They tear down ideas, but fail to offer solutions. Usually this is about their ego rather than a desire to help the team.
I agree that's a dark pattern and something I hope I have never been (I realize you weren't accusing me of that).
I try to ask questions like, "What happens when X goes down?" What happens when network latency goes up?
I quit a job over this one. I had designed an API for a consumer IP/IR control type thing. You say, "I want to tell that thing over there to turn on." The API does the thing, and then exits. The API does retain state-- but only in as much as it wakes up when it gets a packet from a device, parses it, etc, and makes any internal state changes.
Well, management decided they wanted to demo it running continuously for days at CES. Now if you've never done a demo for CES-- it is the worst environment possible. Networks go up and down, there is so much radio traffic that WiFi, BT, anything are unreliable.
I told them I would need to harden the API, that it wasn't designed for that scenario and most of our tests didn't last more then a few seconds keep in mind that at this time, this was a skunk works sort of thing that had not yet been productized. Also, keep in mind there was an aggressive, aggressive development schedule.
They predictably lost their minds. I know its crazy right? Test for the exact scenario you plan to show to customers? They forbade me for doing any sort of test like that and charged ahead with the demo. A month later a manager dressed me down in front of my entire team. About the bug that they had forbade me to fix.
I walked out and never went back.
EDIT: That turned out to be more of a story about ruthless management and constructive dismissal.
My approach was to allocate 2 weeks for even the most basic things because unknowns always creep in and a tighter schedule tends to make those things creep in even more. Also, many of the requests had no particular urgency to begin with.
On the flip side, I'm sure you retained more old business. And employees: trudging through pre-doomed projects was a major root cause of talent and motivation drain at most B2B places I've worked.
I do exactly the same thing - it's all part of the project and system analysis and it helps you neatly sidestep potential pitfalls.
It reminds me of the whole "hero developer" or "hero team" myth; teams who do not do proper analysis, build a turd, but work insane hours stopping the turd falling to pieces.
The people who do that come out looking like heros, when they could have totally avoided the drama in the first place.
It can depend on accountability mechanisms. I would like to see more contracts that give bonuses to companies that come in under budget and under schedule and penalize the overly optimistic ones that never seem to hit their target. This is becoming more common in some domains.
My contract manufacturing company does this. Our standard contract has a 5% bonus for being less than 10% late on the delivery date (and penalties start around 25% late). After suppliers see the contract they will often revise their originally quoted schedule.
The predominant domain to use this type of contract is infrastructure construction. I haven’t personally seen it used in software development outside of control systems but I can’t immediately think of reasons why it couldn’t be extended to other domains as well
