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.
Suppose I wanted to kill a lot of pilots
91–100 of 178 posts
Re: Suppose I wanted to kill a lot of pilots
#92I 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…
You need a distinct pre-mortem where everybody brings a list of the ways a project could fail. https://en.wikipedia.org/wiki/Pre-mortem
I just deployed something worldwide that took about six weeks to develop and our initial guess was about two weeks, so this is fresh in my mind. I was able to lay out a list of work items at the beginning that stayed like 80% the same from the beginning to the end, but didn't account for the possibility that each one of these could be push-button, or could lead to a blocking problem that needed a day or two of research to resolve. Based on that, I'm thinking that the way to approach the next one of these is to lay out the roadmap, but assume that something like half of the trivial steps are going to turn into complex problems that stop the train for a day or two, or lead to a change in the design.
Re: Suppose I wanted to kill a lot of pilots
#93I 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…
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.
Or acknowledge that the "E" in "ETA" stands for "estimated", not "promised".
Re: Suppose I wanted to kill a lot of pilots
#94Earlier quoted context omitted.
Thé irony being that JavaScript doesn't add anything that Smalltalk didn't already provide, yet we have all this OOP backslash and how FP is somehow better.
Well, Javascript is the language that is able to run everywhere, so that's what frontend engineers have to target. There is some more flexibility now with Webassembly... If you are interested, look up Fable, Bolero, Elm, PureScript, ClojureScript, Grain...
[deleted]
Re: Suppose I wanted to kill a lot of pilots
#95This is a common pattern, also found in proofs by contradiction and optimization techniques. If you know how to find the minimum, you may be able to use that knowledge to find the maximum.
The problem with using this pattern in real life is that it rarely applies. Unlike the one-dimensional toy examples, in real life there are many more ways to fail than there are to succeed. Eliminating or even enumerating all possible ways to fail may be prohibitively expensive. Even if you do that, you only found a way to maintain status quo, not necessarily to improve.
This can be said about the rest of TRIZ/TIPS. I learned about it a long time ago, but can't remember a single time I solved a practical problem by applying it. I may be able to find examples that can be classified under one of TRIZ rules, but only in hindsight. It's not like you can look at a new problem, apply TRIZ approaches one by one, and find a solution faster than you normally would.
Re: Suppose I wanted to kill a lot of pilots
#96Suppose you wanted to become as fat as possible, as fast as possible? How would you pull off that trick? You might stop to think about your answer before continuing.
One way that happens all over nature is to gorge on fruit, just like bears and other animals do every fall before they hibernate.[0][1]
An old article from Ken Hutchins entitled "So, Your Ambition Is to Become a Circus Fat Lady?", is essentially a TRIZ failure design for fat loss.[2]
[0] https://peterattiamd.com/rickjohnson/
[1] https://www.amazon.com/Fat-Switch-Richard-J-Johnson-ebook/dp...
[2] https://nebula.wsimg.com/e2e6c217edf4c5dd64bb0486df430804?Ac...
Re: Suppose I wanted to kill a lot of pilots
#97There is a good book employing the TRIZ mindset for self-improvement called "How to Be Miserable: 40 Strategies You Already Use"[0]. Although some of the outcomes the book lead you to can seem banal, if you approach them from the perspective of how to optimize misery, it can give you a new perspective. It certainly did for me in some areas.
CGP Grey also made a video based on the book, called "7 Ways to Maximize Misery"[1] that may be easier to digest.
[0]https://www.goodreads.com/en/book/show/25898044-how-to-be-mi...
Re: Suppose I wanted to kill a lot of pilots
#98HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?
Not thinking in reverse, but starting at the goal and working backwards to the start (thus pruning the graph search space.)
I use it daily.
Re: Suppose I wanted to kill a lot of pilots
#99I 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…
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 raised risk on a must-not-fail deadline, but it actually failed and was the camel straw that brought the project down. (An Oracle product) PM's were didn't appreciate the risk. There's still probably an Oracle VP out there who really doesn't like me for using the established project protocols that allowed me to escalate the issue to the president where I worked and way above the VP in Oracle. On my own initiative I kept the legacy system-- supposedly partly decommissioned-- updated just in case so we could fail-over softly. This was unexpected: When failure became obvious I reminded the VP that I had raised the original risk, and then I had prepared for it. I think their plan had been to box us in to meet their increased $ demands.
It was part of another missed deadline required for a major milestone 25% payment on the contract, and it was a fixed-price contract so they should have absorbed the costs.
Instead, when the failure progressed to my area, we all showed up to work one day and everything was gone. No contactors, nothing was left, like a cleaning crew had cleared it out. A week of negotiations failed when they wouldn't budge from demands for extra $$millions to keep working on the project, plus their missed 25% milestone payment.
Ultimately I lost a years worth of work when things entered lawsuit land and sued each other for breach of contract. (we won-- or settled at least. The fixed price contract was clear, and the missed deadline were partly due to demos of fake functionality that didn't actually exist or components they knew would be EOL'ed after signing the contract & before implementation would begin. The case for outright fraud was pretty strong: We had videos of the demo.)
In case you're wondering, I don't like Oracle. Though with a different product we were still forced to use Oracle DB's. Those I actually don't mind and were a huge step up from the ~2000 MS SQL Server & much older DEC VMS file-based database that wasn't SQL compliant or relational.
Re: Suppose I wanted to kill a lot of pilots
#100There is a good book employing the TRIZ mindset for self-improvement called "How to Be Miserable: 40 Strategies You Already Use"[0]. Although some of the outcomes the book lead you to can seem banal, if you approach them from the perspective of how to optimize misery, it can give you a new perspective. It certainly did for me in some areas. CGP Grey also made a video based on the book, called "7 Ways to Maximize Mise…
Read the book because the video got me interested, one of the most entertaining reads of my life and definitely the one book that could somehow count as self-help that I'd ever recommend.