Live data from Hacker News

Suppose I wanted to kill a lot of pilots

historyofyesterday.com

121–130 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#121

Earlier quoted context omitted.

The reason no one does this is because thr answer is constant "something might fail and add an arbitrary delay" once you hace committed to play the estimation game, you're committed to the delusion and reality checks dont matter. Just stop trying to estimate.

It's not only that. There seems to be a 'political' advantage to overconfidence even given the effect it ought to have on your track record. (This is not advice.)

Yes, and this surprises me each time it happens.

As a for instance, I was the operations lead a couple years ago for a large, customer-facing financial product rollout. The timeline was insanely aggressive, approximately 10 months ahead of my prediction and predicated upon several payment and banking vendors nailing their legacy integrations out of the gate with no delay (perhaps a first in the history of the world). Several of these vendors weren't committed nor was a spec agreed upon prior to the timeline. When raising these concerns everyone acknowledged them, but mitigations or deadlines revisions we not made as it would countermand previously set expectations with the executive team.

The project continued on for another 18 months past the deadline with a "launch" set every three months. Inevitably something would derail it a week beforehand that was unexpected but known months in advance by the project team (e.g. the mainframe the payment vendor uses has a fixed column length. It will take two months to build around this to support xyz).

In the end it got rolled out. Everyone forgot about the delays and the project team was praised as the implementation did better than expected. The same technique is employed once again.

While I don't like it, I now see the estimates and re-estimates as a method for an executive team to manage a project portfolio and prioritization. It's not a good way to do it but it's easy to express priority by simply ranking deadlines.

It's much easier to avoid this in high-trust environments (typically smaller organizations).

Re: Suppose I wanted to kill a lot of pilots

#122

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

I did this recently for a vacation. I asked what would make me miserable on this trip? And solved for those things. It's amazing how good of a time you can have by just avoiding the biggest and most obvious pitfalls.

Re: Suppose I wanted to kill a lot of pilots

#123

Earlier quoted context omitted.

nobody has permission to think about disasters when estimating project completion time I've been a part of a few large scale system implementations and we documented every significant risk to the project at the beginning and as we went if new ones presented themselves. This seemed to be a standard part of the PM's playbook, and I used to to save critical organizational capabilities when things collapsed: ------------…

I’ve struggled with Out of Life support from almost every database vendor. They create something that is very hard to change, upgrade or rip out, and then require you to upgrade it every few years. Lots of hidden costs for the buyer. They’re generally in a better negotiating position than understaffed IT departments.

Out of Life support was a huge issue in the case I outlined above. I kept things ticking over on my side, but there were no more updates from the original vendor except for bespoke work we had to pay them for to complete annual updates for federal compliance issues. Actually we pooled together with a few organizations in the same boat to do that until we rebooted the failed project.

To give the legacy vendor credit though, It was a legacy product 5 years past its "final" EOL and kept honoring the maintenance agreement and providing ToS updates for a long time. In terms of the database itself, it probably helped that it wasn't their own: It was native to OpenVMS and hadn't substantially changed in at least a decade. Ultimately that made data migration a bit easier since industry tools for migrating from VMS systems had reached maximum maturity by the time we got around to it.

I still have a soft spot for that old system though: It lacked any sort of modern functionality newer than about 1995 and the underlying application has it's nroots in the 60's. But it was fast & I had low level access to do some complex things much more easily than the upgraded system (installed about 6 years ago). You won't get much faster than a well-tuned decades-old system running on modern hardware, at least not unless you need something that can handle medium-to-big data.

Re: Suppose I wanted to kill a lot of pilots

#124
post #90

Earlier quoted context omitted.

Not really. Redux doesn't even touch Browser APIs as far as I know. React uses a virtual DOM to avoid DOM unnecessary manipulation, which is slow and error prone. DOM manipulation could be seen as a week point of browsers, and by avoiding it, React is actually a very good ally. Javascript is a dynamically typed language and offers quite a bit of functional programming functionality itself. React and Redux use that to…

> React uses a virtual DOM to avoid DOM unnecessary manipulation, which is slow and error prone. While it may be the case that DOM is far from perfect, React is hardly the only way to avoid it. Even if for your use case avoiding DOM manipulation is necessary (which I strongly suspect is not true for like 95% of people who use React as the framework du jour), there seem to be significantly better thought out approache…

Interpreters are considered elegant, too. For example, Lua is a great little language and it runs everywhere precisely because it's interpreted.

Re: Suppose I wanted to kill a lot of pilots

#125

Before I do anything, I ask myself: 'Would an idiot do that?' And, if the answer is yes, I do not do that thing. - Dwight Schrute

"Would an idiot eat breakfast?" Uh oh.

an idiot would eat an ordinary breakfast. I will eat an extraordinary breakfast.

Re: Suppose I wanted to kill a lot of pilots

#126
post #88

Earlier quoted context omitted.

PI Planning in SAFe explicitly calls for this. Risks to the plan are called out in front of everyone and each is discussed to see if it can be mitigated (and who will own that mitigation). If anything happens due to one of those foreseen issues, everybody knew about it in advance and already discussed what, if anything, could have been done to prevent it as well as what action was actually taken. I love the SAFe / PI…

The tension I've seen at most places where this goes off the rails is due to mis-assigning responsibility. PMs are responsible for keeping projects on schedule. Engineers are responsible for completing work. Consequently, PMs are incentivized to compresses schedules, and engineers are pressured to do the same. The end result is that "the people who do the work plan the work" goes out the window, because risks aren't…

Yea, I can totally see that happening. Hopefully in a room full of people, somebody will have the gumption to not vote low confidence if there’s concern about this happening.

Re: Suppose I wanted to kill a lot of pilots

#127
At a previous job many years ago, after a project would fail my coworker and I would habitually remark, “we’ve learned another way not to do things!”

There’s just such an abundance of creative ways to screw things up! But that’s kind of the point of the mental model — our brains are pretty good at spitting out tons of ways that things will fail. So hijack that process by making that list and then invert it.

Re: Suppose I wanted to kill a lot of pilots

#129
post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

This sounds very much like formal failure-modes-effects-analysis (FMEA).

https://asq.org/quality-resources/fmea

Re: Suppose I wanted to kill a lot of pilots

#130
post #90

Earlier quoted context omitted.

> React uses a virtual DOM to avoid DOM unnecessary manipulation, which is slow and error prone. While it may be the case that DOM is far from perfect, React is hardly the only way to avoid it. Even if for your use case avoiding DOM manipulation is necessary (which I strongly suspect is not true for like 95% of people who use React as the framework du jour), there seem to be significantly better thought out approache…

Interpreters are considered elegant, too. For example, Lua is a great little language and it runs everywhere precisely because it's interpreted.

Sure, there are many elegant interpreters. I'm not sure that patching DOM from the changes in a redundant data structure is one of them. Even Blink's idea to instead pull browser's own DOM into Javascript definitely looks saner to me.
Post reply on HN