7 ms·

Theory of Constraints

keybored 2y ago
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 2y ago
"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 2y ago
  Surprisingly, "The phoenix Project" is a novel. It's a great book.
  - sevagh 2y ago
    Unrealistic book where people around him were willing to change and didn't dig their heels in to protect their fiefdom.
  - psunavy03 2y ago
    It's a horribly amateurish novel that is a decent intro to DevOps principles.
    - Jtsummers 2y ago
      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 2y ago
    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 2y ago
  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 2y ago
  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 2y ago
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 2y ago
Somewhat related is _Flying Logic_, which was ostensibly made to to enable ToC-type thinking processes at Northop Grumman. https://flyinglogic.com/ 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 2y ago
  If I may ask, what prompted you to move on from that?
  - ryanjamurphy 2y ago
    I am also curious about this!
    - eespark 2y ago
      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.
ericalexander0 2y ago
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 2y ago
  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 2y ago
    > 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.
Emmarof 2y ago
Very interesting read!
dpc_01234 2y ago
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 2y ago
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 2y ago
  +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.
  - xupybd 2y ago
    Wait there is a movie?
    - user_7832 2y ago
      Yep! It’s a bit old and 720p-ish but there’s a movie, I think it was even on YouTube at one point.
ezekiel68 2y ago
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.
- pvdoom 2y ago
  > one may make good progress tuning one part of a system only to discover that a larger constraint prevails as the true bottleneck. In my latest job this was exactly the case. We were modernising a good old big ball of mud. And we made very decent progress on a part that was supposed to read from an API. That was nice but turned out that the API itself is poorly designed, and the vast majority of problems and slowdowns are coming from the other side. And the true bottleneck was that the team responsible for data was not very well prepared, so there was little design, poor coding, etc. And what really turned out to be the bottleneck is that the entire department just has a problem with processes and with hiring and retaining qualified people, and with ups killing the existing ones ...
killthebuddha 2y ago
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 2y ago
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.
- wheelinsupial 2y ago
  There is the Franz Edelman award from INFORMS [1] that used to publish accessible articles about how OR techniques are being used in industry. The MIT LGO program has some theses published online that show how OR techniques are applied at smaller scale in industry. I’ve been involved in some smaller scale projects that used mathematical programming techniques to help with scheduling manufacturing lines and call center shifts. We’ve used simulation to help understand how improvements can be made in call centers and warehouses. Lots of this stuff is under industrial engineering at the operational level. At the supply chain level, often a company is using the services of someone else. Sometimes they’ll have industrial engineers working with these techniques. [1] https://www.informs.org/Recognizing-Excellence/INFORMS-Prizes/Franz-Edelman-Award https://www.informs.org/Recognizing-Excellence/INFORMS-Prize...
- pvdoom 2y ago
  I've been rather nerdy on Operations Research. It seems that today it's a mostly unknown field limited to few companies. Maybe it turned out to be too difficult for ordinary managers, who just wanted dashboards, maybe people weren't really ready for it, maybe it got crushed by the agile industrial context ... but if you look at writings from the 70s and 80s it seems that there is an agreement that for an OR department to be truly successful it would require a mandate to truly transform the business and disrupt common power structures - which is why instead they often get relegated to just doing dashboards. Over time they became data analysts and then the data scientists of today. I personally think that there is a LOT of very useful stuff in the field.
sebastianconcpt 2y ago
Reminded me of this in Smalltalk-76 https://github.com/cdglabs/thinglab https://github.com/cdglabs/thinglab

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 2y ago

"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 2y ago
Surprisingly, "The phoenix Project" is a novel. It's a great book.
- sevagh 2y ago
  Unrealistic book where people around him were willing to change and didn't dig their heels in to protect their fiefdom.
- psunavy03 2y ago
  It's a horribly amateurish novel that is a decent intro to DevOps principles.
  - Jtsummers 2y ago
    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 2y ago
  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 2y ago
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 2y ago
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 2y ago

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 2y ago

Somewhat related is _Flying Logic_, which was ostensibly made to to enable ToC-type thinking processes at Northop Grumman. https://flyinglogic.com/ 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 2y ago
If I may ask, what prompted you to move on from that?
- ryanjamurphy 2y ago
  I am also curious about this!
  - eespark 2y ago
    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.

ericalexander0 2y ago

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 2y ago
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 2y ago
  > 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.

Emmarof 2y ago

Very interesting read!

dpc_01234 2y ago

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 2y ago

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 2y ago
+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.
- xupybd 2y ago
  Wait there is a movie?
  - user_7832 2y ago
    Yep! It’s a bit old and 720p-ish but there’s a movie, I think it was even on YouTube at one point.

ezekiel68 2y ago

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.

pvdoom 2y ago
> one may make good progress tuning one part of a system only to discover that a larger constraint prevails as the true bottleneck. In my latest job this was exactly the case. We were modernising a good old big ball of mud. And we made very decent progress on a part that was supposed to read from an API. That was nice but turned out that the API itself is poorly designed, and the vast majority of problems and slowdowns are coming from the other side. And the true bottleneck was that the team responsible for data was not very well prepared, so there was little design, poor coding, etc. And what really turned out to be the bottleneck is that the entire department just has a problem with processes and with hiring and retaining qualified people, and with ups killing the existing ones ...

killthebuddha 2y ago

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 2y ago

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.

wheelinsupial 2y ago
There is the Franz Edelman award from INFORMS [1] that used to publish accessible articles about how OR techniques are being used in industry. The MIT LGO program has some theses published online that show how OR techniques are applied at smaller scale in industry. I’ve been involved in some smaller scale projects that used mathematical programming techniques to help with scheduling manufacturing lines and call center shifts. We’ve used simulation to help understand how improvements can be made in call centers and warehouses. Lots of this stuff is under industrial engineering at the operational level. At the supply chain level, often a company is using the services of someone else. Sometimes they’ll have industrial engineers working with these techniques. [1] https://www.informs.org/Recognizing-Excellence/INFORMS-Prizes/Franz-Edelman-Award https://www.informs.org/Recognizing-Excellence/INFORMS-Prize...
pvdoom 2y ago
I've been rather nerdy on Operations Research. It seems that today it's a mostly unknown field limited to few companies. Maybe it turned out to be too difficult for ordinary managers, who just wanted dashboards, maybe people weren't really ready for it, maybe it got crushed by the agile industrial context ... but if you look at writings from the 70s and 80s it seems that there is an agreement that for an OR department to be truly successful it would require a mandate to truly transform the business and disrupt common power structures - which is why instead they often get relegated to just doing dashboards. Over time they became data analysts and then the data scientists of today. I personally think that there is a LOT of very useful stuff in the field.

sebastianconcpt 2y ago

Reminded me of this in Smalltalk-76 https://github.com/cdglabs/thinglab https://github.com/cdglabs/thinglab