I can derive 3X: Explore/Expand/Extract from the Kelly Criterion. Explore: make more, smaller bets when the probability of failure (experiment returning the undesired outcome) is high & the payoff is high.
Expand: make one bet at a time when the cost of failure is total & the probability of success is reasonable.
Extract: make a few large bets when the probability of success is high & the payoff (as a percentage) is low (the absolute numbers will be huge compared to Explore).

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Kent Beck

Kent Beck Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @KentBeck

27 Jan
The goal of software design is to create chunks or slices that fit into a human mind. The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes.
This implies that software design is a human process with technical support, done by humans for humans. As shiny as the technical support is it took me a while to acknowledge that messy people stuff.
I’ll add that “fits into” and “maxes out” are metaphors and not precisely true, but they help make sense of a healthy, growing urge to re-design. Knowledge is not a quantity & the brain is not a space & we work together.
Read 4 tweets
11 Nov 20
As part of yesterday's Invitation to Systems Thinking workshop @jessitron prepared a short play from which the students would draw various diagrams of the software development system described. At one point the manager says, "This is not acceptable," and it hit me hard in layers.
Layer 1: of course it's acceptable. You've been working like this for months, maybe years. You've accepted it all along.
Layer 2: of course it's not acceptable. If you keep going like this you'll be out of business in a year or two, maybe sooner. Something does need to change.
Read 7 tweets
18 May 20
A story about human connection.

I've played guitar and sang for 50 years. I rarely play for anyone else. I'm haunted by the feeling that I need to be better before exposing myself to others. (Deep roots to this--story for another day.)
I have a love/hate relationship with practicing. Sometimes I do it and love it, the sense that I know where the boundaries are and I know if I'm doing it right. Sometimes I do it and hate it, since I could always be faster and cleaner.
Often I don't practice. It's exhausting not knowing whether I'm going to drift into OCD bliss or savage myself. And then I beat myself up for not practicing. (Don't worry, we're getting to the connection/redemption part of the story.)
Read 9 tweets
7 Jan 20
Re: observing effort/output/outcome/impact. Here's a concrete comparison of tweets, blogs, and videos.
Effort (time invested per item)
* Tweet--5 minutes
* Blog--2 hours
* Video--1 hour
Output (what I produced across the last quarter)
* Tweet--44
* Blog--5
* Video--7
Read 8 tweets
27 Aug 19
My disagreements around planning seem to revolve around metaphor: a plan is X. Different answers for X lead to different behaviors and different evaluation of outcomes.
“A plan is a prediction of the future” is a common metaphor. Nobody out and says that, because it is absurd in an atmosphere of substantial change, but that’s how some folks act.
“A plan is a chance to escape a local maximum” leads to different plans and planning. This plan is about stepping back from execution to see if there is a different path entirely.
Read 5 tweets
4 May 19
While working on #TidyFirst this visualization of why software design is a human relationship problem popped up. Thread
The cliche product/engineering split has someone with an idea waiting for the behavior of the system to change so they can analyze feedback. These are the “waiters” (seems enough time has passed to reuse this word).
The makers actually change the behavior of the system. They also change the structure of the system, because the structure affects how they can change the behavior.
Read 6 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!