I know most people are gushing with positives ... but to me this reads like the epitome of a clueless consultant who got lucky because the 30 plus years manager missed the basics ... unless the era of the tale was early 60s or something or some middle of nowhere fabrication that sprang up with little idea of how other similar places work ... um great story but what really was this based on.
In the industry it's fairly well known (ok that's a weasel phrase even though I'm sure I'd be right if I used 99.999999%) in regard to the overall benefits of TAs (Trade Assistants.) Typically a TA around welders, they're grinding and readying the surfaces to be welded and helping position the work. Though there's value in setting up, not just making blue light, welders generally receive a much higher pay packet, since ultimately it's their good welding skills that ensures quality welds leave the floor and a long life of the component.
What's obvious is what would have happened if the blue light was 50 or 60% of the time and the welding machines were at capacity. (Higher capacity welding machines are generally a lot more expensive.) To the clueless a lot more can be squeezed out ... and that's what the hero would have aimed to do, in fact no doubt another 25%. The experienced plant manager would have then kindly thanked them at that point perhaps realising the consultant was out of their depth.
To be fair, the situation in the story truly does happen in a variety of jobs and businesses.
What you are highlighting is the countervailing lesson, kind of a specialization of Chesterton's fence: if highly experienced people are doing a process in what seems to be an inefficient manner, consider that it might actually be the most efficient manner, given constraints that you do not fully understand or are not aware of.
the story seems to be set in a world that uses gas to weld steel as part of a production process, making a blue flame. are there any torches that can weld steel and make a blue flame? does anyone use manual gas welding in automotive production‽
Great article. It is almost always the case that we live under "assumed constraints". Most of the time when we question the underlying assumptions we are able to break the constraint or relax it to obtain a better solution.
The Goal, by Eliyahu M. Goldratt is highly recommended for understanding Theory of Constraints told from the view of a fictional plant manager.
I read that, having received a similar recommendation, but after I finished it I had no idea how to translate that into my own job (I do not manage a factory).
Bullshit story the consultant made up to bolster his point (93% efficiency claim from a foreman wtf).
Of course finding some help moving parts around for the welders would be the first thing the foreman would think of, because thats what foremans do all the time in factories.
Maybe the welders chose to work this way (i.e. inefficiently) because continuous welding produces fatigue which risks H&S and lowers the quality of the product.
So if the story was real, the solution would be extra personnel so the welding is done continuously, by rotating people between welding, moving parts and other jobs.
This has to be either the world's dumbest foreman or at least largely fiction. And this consultant would have had to have been the first guy who walked into the shop besides the foreman and the welders who either also had never worked in a functioning production environment or had already told the foreman to hire a material handler and been ignored. Or they really liked the overtime and dragging pallet jacks around.
I've seen some pretty terrible inventory management and poor process flow, but this is a whole other level.
The story might not be a accurate, but the concept is certainly valid. I see this sort of thing all the time. This terrific story helps people to understand the core point, that busy does not equal productive.
It's incredible that one person was able to handle all the work that took up 90% of the welders time. Lots of time must have been spent getting in and out of gear. I’d expect that one guy to end up the bottleneck and the welders to be waiting for him to bring them parts, but it says he even as time to peel the plastic!
I imagine the blue light applied to programming would be a crude tool. I want to hear keys clacking? See issues closed, pull requests? But we can ask what are the things developers are doing which interrupt them from coding and could there be a benefit to someone employed to handle those distractions?
> Lots of time must have been spent getting in and out of gear.
My understanding from reading that is the new helper didn't have to get in and out of gear. He wasn't a welder, so wasn't wearing any of the welding gear. His job was to help move things around, position materials so they'd be ready to work on, and generally get the "grunt work" out of the way so the welders could keep their gear on 100% of the time and thus spend most of their time doing their actual specialty: welding.
The new helper was essentially a new floating resource who could quickly move anywhere in the room to clear bottlenecks. Before he was there, the bulk of the time that was wasted was because the welders had to keep context switching, and also because there was some work that the welders were doing sequentially that could have been done in parallel if they had another pair of hands to set things up just right.
Also consider that I'm sure it wasn't really 90% of the welders' time. Even if the author was only seeing blue light 10% of the time, I'm sure these changes didn't bring it up to 100%. There were probably still some non-welding things the welders had to do that couldn't be delegated to others.
For me, the programming equivalent of the blue light is my development environment being in focus, and receiving key strokes and mouse clicks.
Crude but surprisingly accurate. If I am not interacting with my development environment, it usually mean there is a problem somewhere. Sometimes that's me (slacking off, getting lost,...), sometimes it is organisational (useless meetings and processes,...), sometimes technical (slow computer, unresponsive network,...). But it is always a sign of inefficiency.
So the derivation of Eli Goldratt’s ideas for programming is necessarily different because we are doing artisanal work rather than manufacturing. But yes taken naively it is a measure of Git commits merged into the main branch after running precommit checks and tests and code review and whatever else, and ideally shipping to prod directly. And this is where you want to enable the ability to ship broken code without breaking prod (feature toggles are super handy for this)... This speeds the code review time for example, “oh all that stuff is behind a feature toggle, we won't ship it until it's ready.”
A better derivation of Eli's ideas ultimately causes your entire team to work on one feature before deploying another before deploying another. Sprint planning is “what do we want to take on next, how are we separating it across the team, and how will we pass the baton?” The relay-race baton-pass becomes the crucial concept, whoever has the baton is expected to be working 100% on this thing and only this thing, anyone who does not have the baton is either meant to be preparing to receive the baton, or else they are free to work on whatever refactoring or bug-fixing or side-feature or user support or whatever needs to be done. They are the equivalent of this non-welder helping out. And this is also why it's important for the baton to pass from person to person, because it can be exhausting to hold the baton for too long: what do you call someone who sprints for an hour—a jogger.
This also unlocks the true value of daily standup, which is the person with the baton telling everybody else what they need in order to be successful, and the person who is about to receive the baton to be aware about the timescale at which they have to drop everything else they are doing and work 100% on the next part of the sprint, and the rest of the team checking in on the personal health of the person who has the baton, making sure that they are not overworking themselves to death. Are you okay?
What's at stake is covered in Goldratt’s book Critical Chain, that in a “project context” there is a complex network of dependencies, including hidden ones that come from the raw logical fact that one person can't be working on two different parts at the same time, and the constraint, the thing that actually needs to be tracked and preserved is temporal safety buffer. The default state for a project is that if a step is completed late, that delay has passed on to the next step, but if a step is completed early, that advantage is not communicated to the next step because the person working on the next step isn't ready to drop everything and start working on the project yet.
I actually use these principles to manage the cooking of Thanksgiving meals for our family. My wife was very upset the first time I did it because there was a lot of drawing graphs and stuff, a bunch of diagrams, I had never done it before. But now she wants me to do it every year because it is absolutely intoxicating for her to ask me “what should I be doing right now?” and for me to reply “ nothing, you should rest, but in about 30 minutes you are going to have to drop whatever you are doing and put together everything for the corn casserole.”
That this is how it works should not shock us, not those of us working in web development. Everybody here who works in web development should understand that you overprovision your servers and 90% of the time. They don't do anything. That's not for no reason, it's not because we're wasteful, it because it gives us a much better latency on our incoming requests. Making it clear what the Sprint goal is, and whose shoulders that goal is currently falling upon, is part of making a very low latency system which can respond to whatever fires occur on a day-to-day basis while still getting these longer term projects done ahead of schedule. 80% of the team should be resting or dealing with the latest crisis while one person is legit sprinting on the Sprint goal, and progress on a feature should never have to stall just because the sprinter's significant other is suddenly in the hospital: the feature was owned by the team and the whole team needs to be able to work on it, with everybody checking their work in daily and everybody willing to help out to make the group's deadlines.
I've kind of given the sales pitch for it so let me give one major limitation, a lot of our current methodology is structured in order to identify underperforming people by concrete metrics like how many features they complete, how many story points are those features, and the above methodology kind of creates a space where people can hide: they never take the baton so they never are really in the hot seat, but the whole group takes credit for the success of their individuals. Random assignment and pair programming are one mechanism to rectify the concern and then rectify an obvious concern with that solution (“what if we give a frontend task to a backend programmer?”—answer is, they should do the frontend task, but as the person holding the baton they are running the show and thus entitled to say “I want help, can someone who knows more about frontend code pair with me so that I can just ask “how do I do that in the browser?”).
My current environment... we develop on a production environment.
And our toolchain... put it this way. We went from no documented procedures, to several. And the several... have no date, no version, no author, no revision control...
I had to beg for a simple server to separate staging and customers demos once, that were jamming up half a day a week.
The official request I made said the server would pay for itself in eight weeks. I think the boss finally understood why I was being so grumpy about it at that point. Or maybe you could just trust the people you claim to trust.
The article's story anecdote of "blue light" is about finding the true value in a process. Blue light means the welder is actually creating value in the product. Anything else in the process does not help build value to the product. It is all non-value added activities. The non-value added activities might be necessary such as setup, delivery, reposition or what not but it doesn't drive value. By maximizing the blue light welding operation it maximizes value being created. Maximizing value will minimize extraneous activities that don't help make a finished product and should decrease cycle time for the value-added activity.
This all can be learned from The Goal by Goldgratt which is a story about theory of constraints.
Those are things are also necessary, they just don't require a welder to do them. All the talk of "value" will pollute your thinking and encourage you to be a productivity and value bigot.
Your comment reads like you have an ax to grind against consultants and have a foregone conclusion separate from the content?
In this story, the consultant found a way to remove stupid/low-skilled work from the welders' todo. They no longer have to lift shit, take off their gear, and peel plastic off parts. None of that sounds fun and presumably welders are happy not to be doing that.
I suspect a welder prefers to weld. The consultant found a way to let welders do what they chose/are trained to do, which is weld. I don't see any sort of bullshit metric/target imposed on them.
This is a great story because it's not just about welding. I have seen many data science teams working under similar conditions: spending 90% of their time doing miscellaneous bullshit and 10% doing data science at best.
Recall that data science itself is 80-90% data cleaning and basic exploratory analysis, so that means no more than 1-4% of their overall time is spent doing the work that they're actually trained to do, and that you are actually paying them to do.
They look productive because they are always busy. But really they need helpers (data engineers and dev/data ops people) to do all the random software work, so the data scientists can actually build models, meet with senior leadership, and all the other actually value-generating work that justifies their high price tag, and moreover keeps them happy with the work so they are more likely to actually stay at your company.
That can still be ridiculously profitable if the output is good enough and general enough. The human mind has insane leverage, especially in the modern world.
For example, Newton / Leibnitz's invention of calculus created much more than enough value to pay for every single mathematician ever since, and that wasn't even all they did.
Even if the story is true, taking this attitude to the extremes is what leads companies like Amazon to time warehouse workers down to the last second and set increasingly aggressive targets every year. It is easy to deal with people when they are just a bunch of numbers in a excel sheet.
No wonder they are going to run out of workers to hire in the US by 2024, as their own memo said.
No need to ask people to work more or harder - just show/allow them to work more efficiently and they can generate more value with less/same overall effort.
Better to have a more relaxed and achievable target of 100 units with a more efficient way of working than to have a more difficult target of 50 with a less efficient one. Right?
Regarding so many other comments from people who know a lot about welding and/or factories who think the story is made up. Probably you're right, but THE STORY IS NOT ABOUT WELDING!
It is about having misconceptions about efficiency and productivity, and that people being busy does not mean they can't be more productive.
> I then watched the first welder begin to peel the protective plastic coating off the bumper in the places he had to weld. It took a good bit of time picking with his fingernails to get it done.
Seems like this whole step could be eliminated if they only protected the areas that weren’t going to be welded. You don’t care about cosmetic damage to surfaces you’re going to weld on. Just be smarter about where you put the plastic.
There might be good reasons why they did that though. My experience in factory settings is that there is always a reason. It’s just sometimes a really dumb one.
It seems like a story that works well in a factory setting - where its not particularly creative work and you do the same thing over and over again.
The basic gist of the story is an assembly line improves efficiency in a factory. Well no duh.
The translation of that lesson to a programming environment seems like it would be really fraught, encouraging people to do stupid things like write more unnessary lines of code.
I think it's meant to be interpreted as "hiring additional welders would be creating capacity for nothing" because the number of welders was not the bottleneck.
[+] [-] anenefan|3 years ago|reply
In the industry it's fairly well known (ok that's a weasel phrase even though I'm sure I'd be right if I used 99.999999%) in regard to the overall benefits of TAs (Trade Assistants.) Typically a TA around welders, they're grinding and readying the surfaces to be welded and helping position the work. Though there's value in setting up, not just making blue light, welders generally receive a much higher pay packet, since ultimately it's their good welding skills that ensures quality welds leave the floor and a long life of the component.
What's obvious is what would have happened if the blue light was 50 or 60% of the time and the welding machines were at capacity. (Higher capacity welding machines are generally a lot more expensive.) To the clueless a lot more can be squeezed out ... and that's what the hero would have aimed to do, in fact no doubt another 25%. The experienced plant manager would have then kindly thanked them at that point perhaps realising the consultant was out of their depth.
[+] [-] nerdponx|3 years ago|reply
What you are highlighting is the countervailing lesson, kind of a specialization of Chesterton's fence: if highly experienced people are doing a process in what seems to be an inefficient manner, consider that it might actually be the most efficient manner, given constraints that you do not fully understand or are not aware of.
[+] [-] yuubi|3 years ago|reply
[+] [-] vivegi|3 years ago|reply
The Goal, by Eliyahu M. Goldratt is highly recommended for understanding Theory of Constraints told from the view of a fictional plant manager.
[+] [-] hn_go_brrrrr|3 years ago|reply
[+] [-] giorgosts|3 years ago|reply
Of course finding some help moving parts around for the welders would be the first thing the foreman would think of, because thats what foremans do all the time in factories.
Maybe the welders chose to work this way (i.e. inefficiently) because continuous welding produces fatigue which risks H&S and lowers the quality of the product.
So if the story was real, the solution would be extra personnel so the welding is done continuously, by rotating people between welding, moving parts and other jobs.
[+] [-] nerdponx|3 years ago|reply
The critical difference is that they did not need to hire more welders, buy more welding equipment, set up more welding stations.
I don't care if the story came right out of Aesop's fables, because it's a good story and it makes a good point.
[+] [-] msrenee|3 years ago|reply
I've seen some pretty terrible inventory management and poor process flow, but this is a whole other level.
[+] [-] paul_f|3 years ago|reply
[+] [-] twobitshifter|3 years ago|reply
I imagine the blue light applied to programming would be a crude tool. I want to hear keys clacking? See issues closed, pull requests? But we can ask what are the things developers are doing which interrupt them from coding and could there be a benefit to someone employed to handle those distractions?
[+] [-] kelnos|3 years ago|reply
My understanding from reading that is the new helper didn't have to get in and out of gear. He wasn't a welder, so wasn't wearing any of the welding gear. His job was to help move things around, position materials so they'd be ready to work on, and generally get the "grunt work" out of the way so the welders could keep their gear on 100% of the time and thus spend most of their time doing their actual specialty: welding.
The new helper was essentially a new floating resource who could quickly move anywhere in the room to clear bottlenecks. Before he was there, the bulk of the time that was wasted was because the welders had to keep context switching, and also because there was some work that the welders were doing sequentially that could have been done in parallel if they had another pair of hands to set things up just right.
Also consider that I'm sure it wasn't really 90% of the welders' time. Even if the author was only seeing blue light 10% of the time, I'm sure these changes didn't bring it up to 100%. There were probably still some non-welding things the welders had to do that couldn't be delegated to others.
[+] [-] nikanj|3 years ago|reply
[+] [-] GuB-42|3 years ago|reply
Crude but surprisingly accurate. If I am not interacting with my development environment, it usually mean there is a problem somewhere. Sometimes that's me (slacking off, getting lost,...), sometimes it is organisational (useless meetings and processes,...), sometimes technical (slow computer, unresponsive network,...). But it is always a sign of inefficiency.
[+] [-] taneq|3 years ago|reply
[+] [-] crdrost|3 years ago|reply
A better derivation of Eli's ideas ultimately causes your entire team to work on one feature before deploying another before deploying another. Sprint planning is “what do we want to take on next, how are we separating it across the team, and how will we pass the baton?” The relay-race baton-pass becomes the crucial concept, whoever has the baton is expected to be working 100% on this thing and only this thing, anyone who does not have the baton is either meant to be preparing to receive the baton, or else they are free to work on whatever refactoring or bug-fixing or side-feature or user support or whatever needs to be done. They are the equivalent of this non-welder helping out. And this is also why it's important for the baton to pass from person to person, because it can be exhausting to hold the baton for too long: what do you call someone who sprints for an hour—a jogger.
This also unlocks the true value of daily standup, which is the person with the baton telling everybody else what they need in order to be successful, and the person who is about to receive the baton to be aware about the timescale at which they have to drop everything else they are doing and work 100% on the next part of the sprint, and the rest of the team checking in on the personal health of the person who has the baton, making sure that they are not overworking themselves to death. Are you okay?
What's at stake is covered in Goldratt’s book Critical Chain, that in a “project context” there is a complex network of dependencies, including hidden ones that come from the raw logical fact that one person can't be working on two different parts at the same time, and the constraint, the thing that actually needs to be tracked and preserved is temporal safety buffer. The default state for a project is that if a step is completed late, that delay has passed on to the next step, but if a step is completed early, that advantage is not communicated to the next step because the person working on the next step isn't ready to drop everything and start working on the project yet.
I actually use these principles to manage the cooking of Thanksgiving meals for our family. My wife was very upset the first time I did it because there was a lot of drawing graphs and stuff, a bunch of diagrams, I had never done it before. But now she wants me to do it every year because it is absolutely intoxicating for her to ask me “what should I be doing right now?” and for me to reply “ nothing, you should rest, but in about 30 minutes you are going to have to drop whatever you are doing and put together everything for the corn casserole.”
That this is how it works should not shock us, not those of us working in web development. Everybody here who works in web development should understand that you overprovision your servers and 90% of the time. They don't do anything. That's not for no reason, it's not because we're wasteful, it because it gives us a much better latency on our incoming requests. Making it clear what the Sprint goal is, and whose shoulders that goal is currently falling upon, is part of making a very low latency system which can respond to whatever fires occur on a day-to-day basis while still getting these longer term projects done ahead of schedule. 80% of the team should be resting or dealing with the latest crisis while one person is legit sprinting on the Sprint goal, and progress on a feature should never have to stall just because the sprinter's significant other is suddenly in the hospital: the feature was owned by the team and the whole team needs to be able to work on it, with everybody checking their work in daily and everybody willing to help out to make the group's deadlines.
I've kind of given the sales pitch for it so let me give one major limitation, a lot of our current methodology is structured in order to identify underperforming people by concrete metrics like how many features they complete, how many story points are those features, and the above methodology kind of creates a space where people can hide: they never take the baton so they never are really in the hot seat, but the whole group takes credit for the success of their individuals. Random assignment and pair programming are one mechanism to rectify the concern and then rectify an obvious concern with that solution (“what if we give a frontend task to a backend programmer?”—answer is, they should do the frontend task, but as the person holding the baton they are running the show and thus entitled to say “I want help, can someone who knows more about frontend code pair with me so that I can just ask “how do I do that in the browser?”).
[+] [-] ChrisMarshallNY|3 years ago|reply
It was like pulling teeth, but, in fairly short order, the chap I hired became the most popular member of the team.
[+] [-] slowhand09|3 years ago|reply
And our toolchain... put it this way. We went from no documented procedures, to several. And the several... have no date, no version, no author, no revision control...
Friday is my last day. I am so happy.
[+] [-] hinkley|3 years ago|reply
The official request I made said the server would pay for itself in eight weeks. I think the boss finally understood why I was being so grumpy about it at that point. Or maybe you could just trust the people you claim to trust.
[+] [-] larrydag|3 years ago|reply
This all can be learned from The Goal by Goldgratt which is a story about theory of constraints.
https://www.tocinstitute.org/the-goal-summary.html
[+] [-] sitkack|3 years ago|reply
[+] [-] mannykannot|3 years ago|reply
So when the downturn comes, fire the trade assistant.
[+] [-] jancsika|3 years ago|reply
Or is the point that a good consultant knows to leave before that happens?
[+] [-] xyzelement|3 years ago|reply
In this story, the consultant found a way to remove stupid/low-skilled work from the welders' todo. They no longer have to lift shit, take off their gear, and peel plastic off parts. None of that sounds fun and presumably welders are happy not to be doing that.
I suspect a welder prefers to weld. The consultant found a way to let welders do what they chose/are trained to do, which is weld. I don't see any sort of bullshit metric/target imposed on them.
[+] [-] count|3 years ago|reply
[+] [-] danuker|3 years ago|reply
[+] [-] nerdponx|3 years ago|reply
Recall that data science itself is 80-90% data cleaning and basic exploratory analysis, so that means no more than 1-4% of their overall time is spent doing the work that they're actually trained to do, and that you are actually paying them to do.
They look productive because they are always busy. But really they need helpers (data engineers and dev/data ops people) to do all the random software work, so the data scientists can actually build models, meet with senior leadership, and all the other actually value-generating work that justifies their high price tag, and moreover keeps them happy with the work so they are more likely to actually stay at your company.
[+] [-] FredPret|3 years ago|reply
For example, Newton / Leibnitz's invention of calculus created much more than enough value to pay for every single mathematician ever since, and that wasn't even all they did.
[+] [-] hiAndrewQuinn|3 years ago|reply
[+] [-] omeysalvi|3 years ago|reply
[+] [-] Nifty3929|3 years ago|reply
Better to have a more relaxed and achievable target of 100 units with a more efficient way of working than to have a more difficult target of 50 with a less efficient one. Right?
[+] [-] Nifty3929|3 years ago|reply
It is about having misconceptions about efficiency and productivity, and that people being busy does not mean they can't be more productive.
[+] [-] MisterMower|3 years ago|reply
Seems like this whole step could be eliminated if they only protected the areas that weren’t going to be welded. You don’t care about cosmetic damage to surfaces you’re going to weld on. Just be smarter about where you put the plastic.
There might be good reasons why they did that though. My experience in factory settings is that there is always a reason. It’s just sometimes a really dumb one.
[+] [-] bawolff|3 years ago|reply
The basic gist of the story is an assembly line improves efficiency in a factory. Well no duh.
The translation of that lesson to a programming environment seems like it would be really fraught, encouraging people to do stupid things like write more unnessary lines of code.
[+] [-] yqsk|3 years ago|reply
[+] [-] Scalene2|3 years ago|reply
[+] [-] bmacho|3 years ago|reply
[+] [-] phyzome|3 years ago|reply
[+] [-] zootboy|3 years ago|reply
[+] [-] Exuma|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]