3 ms·

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 ge

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?

nikanj 4y ago
Not all of it, just enough of it to move the bottleneck somewhere else. A factory is always bottlenecked by something, sales if nothing else
- Dylan16807 4y ago
  > A factory is always bottlenecked by something, sales if nothing else I don't feel like that's a very good conclusion. If a good chunk of your processes have roughly the same capacity, and they're all running at that capacity, you don't have anything I would call a bottleneck.
crdrost 4y ago
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?”).
- Dylan16807 4y ago
  That sounds like an extremely efficient way to get one feature, or a series of overly dependent features, done as fast as possible. But I'm not understanding why that would be your goal except in rare circumstances. Why not have most of the team coding toward the goals and one or two helpers? Especially because that's how the welding story worked.
kelnos 4y ago
> 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.
- msrenee 4y ago
  What gear are they having to take off besides their hood, btw? I'm pretty sure anything you'd need respiratory gear to weld on would be added after it was welded. It's not like you make truck bumpers out of stainless steel. You'd want to keep your gloves on to lift with. No reason to take off your jacket, sleeves, apron, or anything else you'd use welding in a shop.
GuB-42 4y ago
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.
taneq 4y ago
He’s not taking welding gear off and then re-donning it 50 times a day, for starters.

nikanj 4y ago

Not all of it, just enough of it to move the bottleneck somewhere else. A factory is always bottlenecked by something, sales if nothing else

Dylan16807 4y ago
> A factory is always bottlenecked by something, sales if nothing else I don't feel like that's a very good conclusion. If a good chunk of your processes have roughly the same capacity, and they're all running at that capacity, you don't have anything I would call a bottleneck.

crdrost 4y ago

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?”).

Dylan16807 4y ago
That sounds like an extremely efficient way to get one feature, or a series of overly dependent features, done as fast as possible. But I'm not understanding why that would be your goal except in rare circumstances. Why not have most of the team coding toward the goals and one or two helpers? Especially because that's how the welding story worked.

kelnos 4y ago

> 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.

msrenee 4y ago
What gear are they having to take off besides their hood, btw? I'm pretty sure anything you'd need respiratory gear to weld on would be added after it was welded. It's not like you make truck bumpers out of stainless steel. You'd want to keep your gloves on to lift with. No reason to take off your jacket, sleeves, apron, or anything else you'd use welding in a shop.

GuB-42 4y ago

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.

taneq 4y ago

He’s not taking welding gear off and then re-donning it 50 times a day, for starters.