[HN Gopher] Theory of Constraints
___________________________________________________________________
Theory of Constraints
Author : vegetablepotpie
Score : 97 points
Date : 2024-05-01 12:49 UTC (10 hours ago)
(HTM) web link (en.wikipedia.org)
(TXT) w3m dump (en.wikipedia.org)
| keybored wrote:
| _The Goal_ was a fun listen /read. _Wait, if the water fills up
| at 5 liters an hour but the pipe can only support a throughput of
| 2 liters an hour... then we have a whatchamacallit!_
| calvinmorrison wrote:
| "The Goal" has a programming offshot called "The Phoenix
| Project". It may make your blood boil because a lot of the
| situations are tooootally realistic.
| toolslive wrote:
| Surprisingly, "The phoenix Project" is a novel. It's a great
| book.
| psunavy03 wrote:
| It's a horribly amateurish novel that is a decent intro to
| DevOps principles.
| Jtsummers wrote:
| I've read enough business "fables" to say that it's about
| average for that category of writing. It communicates its
| point through the fable, but the novel itself is ok at best
| and certainly not the reason to read it. It does read
| easily since it's not trying to be high literature so it's
| readable in under a week if you can dedicate an hour or two
| each day to it.
| hinkley wrote:
| The Goal is also told in narrative form. It's from the
| perspective of a plant manager whose company is spiraling
| down the drain and his plant has been given 3 months to
| improve their numbers by an exec.
|
| When we first meet the exec he's poking the hornet's nest to
| get a rush order done, and he pisses off a machine tech who
| quits in a huff, accidentally breaking the one machine they
| need the most in the process.
|
| Which is way too close to home for some of us. The guy
| bitching the loudest about the problems is usually the source
| of at least a third of your problems.
| doodda wrote:
| The Phoenix Project should be required reading for anyone in
| the management chain of software development, IT, devops, etc.
| Especially non-technical CEOs.
| from-nibly wrote:
| I needed a paper bag to get through the first part of the
| phoenix project. As a DevOps person it thoroughly stressed me
| out.
| shrubble wrote:
| Lots of good ideas, very thought-provoking when comparing with
| how mgmt at most companies operate.
|
| Be aware however if trying to apply in real life that most
| managers will fight you since it seems counter-intuitive.
| eespark wrote:
| Somewhat related is _Flying Logic_, which was ostensibly made to
| to enable ToC-type thinking processes at Northop Grumman.
|
| https://flyinglogic.com/
|
| For a period in my life I was very taken by the promise of a
| node-based graph visualisation of projects, enabling you to
| quickly track dependencies, constraints, next steps, redundancies
| and so on.
| troelsSteegin wrote:
| If I may ask, what prompted you to move on from that?
| ryanjamurphy wrote:
| I am also curious about this!
| eespark wrote:
| It's not really moving on - I'd still love to have
| something like this, but it's an entire paradigm shift that
| I haven't had the capacity for, not to mention buy-in from
| other parties.
|
| ericalexander0's comment above touches on some of it ("poor
| assumptions, prioritizing ideology over customer value, and
| misaligned shared mental models")
|
| In my particular case, I was expanding a business and
| starting a new one and had just discovered the whole
| "productivity" scene and had naive notions of using task
| management tools and Notion wikis to achieve some latent
| superpowers. But I got into a rabbit hole where nothing was
| good enough, there was always some element of lossiness as
| you moved between tools, and all the tools in the world are
| not a subsititute for having clear mental models and
| actually just getting on with the job rather than thinking
| endlessly about the most beautiful and intuitive ways of
| getting it done.
|
| Separately from these meta-concerns, building and
| navigating a model was not as fluent as a
| Workflowy/Dynalist situation (the latency was small but
| annoying - like early days of Notion), and as your model
| built up and reorganised it was easy to lose track of
| things. There's still some value in graph-based knowledge
| management (e.g. Obisidian), but it's also important to
| remember that storing and having access to information
| (however aesthetically pleasing it might be) is not the
| same as knowing something.
|
| Possibly a larger conversation lurking somewhere about
| productivity, management, the meaning of work, ADHD, and
| friction.
| joenot443 wrote:
| I've personally found Workflowy to be my end-state tool for
| personal project management. I guess you'd call it a hierarchal
| tree.
|
| Node based is fascinating though, I'd love to see what that
| would look like.
|
| https://workflowy.com
| swah wrote:
| I feel like this tool is a bit "what you make of it", do you
| agree? Do you use dates there?
| tunesmith wrote:
| I use this daily as a software architect.
|
| Also for recipes!
|
| And for argument graphs. Premises, therefores/lemmas,
| conclusions.
|
| I don't get heavily into CRT/FRT, at least not the most
| disciplined versions. I find that in practice the kinds of
| problems that justify that in-depth level of analysis are few
| and far between.
| eespark wrote:
| I'm slightly surprised that there's not more mention of
| Flying Logic on here. How do you decide when to use it, and
| what other tools/frameworks do you use in conjunction?
|
| Do you share or collaborate on these models with anyone? I
| find that it's very easy to assume that people will look at
| the model and see what you're seeing but mostly their eyes
| glaze over.
|
| Also: recipes? Just what are you cooking up?
| tunesmith wrote:
| I use it when I want to draw a graphical data structure
| that will visually auto-update as I change it. That answer
| sounds kind of pat, since you basically need to gather
| enough experience to know when that is useful. I tend to
| think it's useful in far many more cases than people
| usually appreciate.
|
| I often screenshare. You can also share the *.xlogic files,
| even via git, although the company has made it harder to
| download a free version of the app that can read them read-
| only. Last I checked it seemed they require a credit card
| even if you don't buy.
|
| The natural representation of a recipe is a DAG! ;-)
| ericalexander0 wrote:
| Check out Beyond The Goal and Beyond The Phoenix Project for a
| deeper dive in this area.
|
| I work in cyber security and use many of the concepts often. The
| root cause of many poor outcomes are poor assumptions,
| prioritizing ideology over customer value, and misaligned shared
| mental models.
|
| I use a simple doc format to address. It's based on evaporating
| clouds.
|
| 1. What's the shared (understanding of current state with a focus
| on objectivity? 2. What are the problems with current state?
| Subjectivity is OK here. 3. What's desired state? 4. What are the
| experiments we can run ASAP to learn if our understanding of
| desired state is correct and learn how we can get closer.
|
| Simple concept. Works great.
| hinkley wrote:
| As computer people, I believe we have access to more
| information on this through the field of Queueing theory.
|
| One of the aspects of Queueing theory is responsiveness, and a
| system with a saturated queue has none. I see this play out
| over and over again in both machine and human capacity
| planning. Even with Agile we can't get stuff done in a
| satisfactory time frame because we always have a backlog sized
| for a team twice the size of the one we have, when
| responsiveness is maximized when the system is running at 50%
| of maximum throughput.
|
| One of my mentors was really into Goldratt and Ohno, but The
| Goal got stuck in my tsundoku pile for years. I'm a third of
| the way through it now (I'm using audiobooks to get through
| books I "should" read but never do), and it is starting to turn
| into thinly veiled queueing theory, but from what my mentor
| said he refers to it instead through the metaphor of drum-
| buffer-rope. But there's a lot more to this field, and as I
| said before, you can apply it to our applications directly, not
| just to the building of them.
| psunavy03 wrote:
| > Even with Agile we can't get stuff done in a satisfactory
| time frame because we always have a backlog sized for a team
| twice the size of the one we have, when responsiveness is
| maximized when the system is running at 50% of maximum
| throughput.
|
| Agile falls down when people misapply it, same as anything
| else. It's not just the size of the backlog; it's being able
| to limit work in progress so that you have the ability to
| adjust. What's more, management needs to get on board with
| the idea of probabilistic forecasting that's continually
| revisited, as opposed to trying to stuff complex work into
| Gantt charts and deadlines. Sadly, most of modern management
| refuses to make these changes, and too many folks in the
| trenches don't want to take ownership of their work and just
| want to be told what to do.
| kjellsbells wrote:
| > management needs to get on board with the idea of
| probabilistic forecasting that's continually revisited
|
| From the manager's pov, though, that just sounds like
| guesswork. "When will my house be built?" "Eh, not sure,
| but theres a 60% chance the framing will be up by July".
|
| Development managers need to learn to communicate on the
| same wavelength as their customers, and vice versa. It
| rarely happens.
| hinkley wrote:
| The thing is construction people do talk like that.
|
| I think that's why rich people often make terrible
| customers. They are just as grouchy at plumbers and
| general contractors as they are at us.
|
| Which reminds me, one of my life goals is to get a full
| rundown of GC tricks to apply to software development.
| I'm running out of time for that to make a quality of
| life difference.
| psunavy03 wrote:
| You're conflating the complicated with the complex.
| Construction workers don't need Agile methods, which is
| why "there's a 60% chance the framing will be up by July"
| sounds so dumb. The physical properties of wood framing,
| electrical wire, shingles, and drywall haven't changed in
| decades. You can make detailed plans around these known
| facts, and workers generally know predictably what it
| takes to build a house.
|
| Software is not like that. Codebases are too big,
| especially counting third-party dependencies. Tech debt
| is lurking everywhere. Customers don't know what they
| want until they see it. So yes, in enterprise-sized
| software, you need probabilistic forecasting precisely
| because you're NOT building a building. It's impossible
| to know things in enough detail up front to make big up-
| front plans that don't largely change like you could if
| you were building a house.
| pwatsonwailes wrote:
| I say this with love but, you've never worked in
| construction have you.
|
| Architects drawings are little more than nicely
| descriptive hopes and sketches of an intended idea, which
| a good contractor has to turn into an actual plan of
| work.
|
| You want to see chaos go talk to the person running the
| development of a high end property in New York.
| hinkley wrote:
| I have a way of getting people to talk to me about their
| professions. At the tail end of a water damage repair,
| the GC confessed to me that they flood customers with
| trivial choices to distract them from the illusion of
| choice in other areas. Like the physics of plumbing
| dictating where sinks can go.
|
| As I mentioned up thread, I want to buy a GC beers and
| get them to tell me more, before I ever take another
| contracting gig.
| InitialLastName wrote:
| > You're conflating the complicated with the complex.
| Construction workers don't need Agile methods, which is
| why "there's a 60% chance the framing will be up by July"
| sounds so dumb. The physical properties of wood framing,
| electrical wire, shingles, and drywall haven't changed in
| decades.
|
| When's the last time you saw a construction project that
| landed on time? Construction projects are a _classic_
| example of forecasting difficulty. Lots of things have to
| go smoothly at the right time, including supply chain,
| coordinating work from multiple organizations (including
| local governments), and the weather has to play nice.
| hinkley wrote:
| There's a modification to Gantt charts that uses Monte
| Carlo simulation to come up with a more believable
| timeline, but nobody likes bad news so it's a fringe Agile
| thing instead of mainstream.
|
| Great companies are few and far between. Everyone else
| thrives on self deception.
| psunavy03 wrote:
| But if you're doing Monte Carlo, you might as well just
| iterate and keep re-running the Monte Carlo as you burn
| through the backlog, because that's a better way of
| having up-to-date information that using any kind of
| Gantt chart.
| hinkley wrote:
| But as I said, the problem isn't really technical
| anymore, it's emotional.
| Jtsummers wrote:
| You don't have to pick one or the other. A Gantt chart is
| just a pretty and easy to read graph based on the
| topological sort of activities and their dependencies and
| durations laid out in time. They also aren't meant to be
| static, unless you're working for a badly managed org
| that uses Waterfall the Gantt chart gets updated as
| things progress and new information comes in.
|
| If you have a backlog, and you don't mark what is
| dependent on what (in progress or also in the backlog)
| you're just hurting yourself. Once you add that
| information and some very basic estimation (even just
| scale of expected effort is enough) you can generate a
| Gantt chart _and_ use Monte Carlo simulations to get an
| understanding of your time estimates.
| hinkley wrote:
| I've only ever seen Gantt charts used by waterfall
| assholes who talk about commitments and promises to get
| free overtime.
|
| Some techniques are good but ruined utterly by the
| company they keep.
| neeleshs wrote:
| In my experience, estimates are the root cause of quality
| problems and expectation mismatches. No one treats them
| as estimates but as actual calendar times.
|
| I've been fortunate to steer my company towards simply
| prioritizing work and communicating the prioritization to
| the rest of the company and more importantly, our
| customers. We don't give time estimates or timelines to
| customers, but provide constant updates on where
| something is. No one has complained about this in
| general. Of course, there are always exceptions - we
| resist them all we can, and that too is reflected as
| reprioritization of backlog.
| andrekandre wrote:
| > No one treats them as estimates but as actual calendar
| times.
|
| its true, though i suspect this is partially because its
| what the management chain wants: a date to report when it
| will be done (e.g will my okr for this quarter be met or
| not?) > estimates are the root cause of
| quality problems and expectation mismatches
|
| i have seen this over and over, most quality issues and
| incidents are caused by decent programmers rushing to
| meet the immovable deploy/release window... because 'your
| not gonna make your estimate'....
| dvfjsdhgfv wrote:
| > too many folks in the trenches don't want to take
| ownership of their work and just want to be told what to
| do.
|
| And do you blame them?
| hinkley wrote:
| If pressed I'll put this as, "once you substituted your
| judgement for mine this became _your_ problem."
|
| I'm not going to enthusiastically absorb the consequences
| of bad decisions I already tried to route us around.
| heymijo wrote:
| OP mentioned The Phoenix Project [1]. It's The Goal applied
| to IT.
|
| One key issue the protagonist has to overcome is how to
| address the issue of an endless backlog.
|
| [1] https://www.goodreads.com/en/book/show/17255186
| dvfjsdhgfv wrote:
| > we always have a backlog sized for a team twice the size of
| the one we have
|
| While it certainly is true, the side-effect is at the same
| time the oldest items in the backlog deprecate with time.
| skybrian wrote:
| A backlog is not a queue. It's just a mutable list. A
| principle of Agile is that you can change your priorities and
| reorganize the backlog to put the currently highest-priority
| stuff first.
|
| (This isn't unique to Agile - any bug database could do this,
| though they don't typically stack-rank things.)
|
| Putting high-priority tasks first increases responsiveness
| for them, but will starve lower-priority tasks. That's
| inherent, but at least management gets to prioritize.
| hinkley wrote:
| > A backlog is not a queue.
|
| That's only slightly true, and it's a dangerous assertion
| from a process standpoint to say it is so. Everything is
| queues. Work in progress, undeployed code, dark features,
| sales pipelines.
|
| There is a queue of requirements we have defined but
| haven't acted upon. That's contained within the backlog,
| along with bug reports and wishful thinking. The backlog is
| approximately a superset of incoming feature request queue
| (modulo anything that skips the backlog and goes straight
| into WIP)
| Jtsummers wrote:
| To expand on your point: Queueing theory applies whether
| the thing is a proper FIFO queue, a LIFO stack, a
| statically prioritized priority queue, a dynamically
| prioritized priority queue, or a bunch of cards grabbed
| randomly out of a hat. If things keep coming in faster
| than they can be handled, the queue, no matter its form,
| will just continue to grow. That a backlog is not a
| proper FIFO queue in most orgs doesn't change this fact.
| skybrian wrote:
| I still think "mutable list" describes the situation
| better than "queue," at least for programmers familiar
| with common data structures. No argument that queuing
| theory is useful.
|
| Defining "responsiveness" in terms of everything that
| anyone has ever wished for seems like a bad thing,
| though. We can have a brainstorming session that comes up
| with a long list of features that would be nice to have,
| end up throwing them out, and that's perfectly fine.
| edorsey wrote:
| It's more of a stream or a pipeline than a queue.
|
| Wait till you realize optimizing data flow through an API
| process serving multiple requests is the same meta problem as
| optimizing value flow through a development team. :)
| Emmarof wrote:
| Very interesting read!
| dpc_01234 wrote:
| Everything in this book applies not only to management, but also
| optimizing distributed systems.
|
| E.g.
|
| - optimizing parts of the system for their own metrics often
| leads to degradation of the whole system performance; any
| optimization must be done w.r.t. the context of the system as a
| whole
|
| - focus on optimizing the bottlenecks
|
| - approach to identifying bottleneck
|
| - minimize amount of stuff waiting in the queues
|
| I love this book. It laid out in an approachable way my
| observations w.r.t how humans fail to organize efficiently by
| just not being good at thinking in terms of a larger system.
| conrs wrote:
| Highly recommend reading or listening to The Goal. The audiobook
| feels like a cheesy training video, but sort of in a good way,
| and the concepts are extremely useful. Plus, you learn the
| language it is more likely your business counterparts know, as
| opposed to talking about backpressure or queuing theory, which
| they may not connect with.
|
| I use the concepts from this book all the time at work to justify
| a prioritized backlog and defend against a lot of work in
| process.
| user_7832 wrote:
| +1 vote for The Goal. Our operations research prof showed us
| the movie in class one day, and it's one of the few things I
| distinctly remember from my courses. It's teachings are crystal
| clear to me years later, although unfortunately/ironically I
| haven't been able to implement it in my life so well.
| ezekiel68 wrote:
| Reading "The Goal" and contemplating how to apply the Theory of
| Constrains to complex software systems a couple of decades ago
| became part of the secret sauce of my career as a software
| engineer. Especially helpful was the insigth that one may make
| good progress tuning one part of a system only to discover that a
| larger constraint prevails as the true bottleneck.
|
| Here's a practical example. For those who may still wrangle
| fleets of actual cloud instances (instead of going the managed
| cluster or serverless route), a common mistake is to imagine that
| all that is needed is a group of the smallest compute units
| available. But with AWS, for example, this can bite you when the
| smallest instances also have dinky allowances for network and/or
| disk I/O compared to medium or larger instances. People end up
| wondering why their queues aren't draining quickly or their DB
| writes or log pipelines are backing up, etc.
| killthebuddha wrote:
| A kind of radical belief that I hold is that basically everyone
| would benefit from working as a planner for a year or two,
| especially if you can spend a good amount of time away from your
| desk and out on the floor. The lessons you can learn by trying to
| coordinate a production floor are simultaneously very general,
| very practical, and oddly difficult to learn elsewhere.
| jhallenworld wrote:
| I'm surprised that there is no mention of Operations Research in
| this article.
|
| I'm actually curious if any business use Operations Research for
| real, vs. managers just guessing. I mean do something like Linear
| Programming to optimize profits based on various constraints.
___________________________________________________________________
(page generated 2024-05-01 23:01 UTC)