[HN Gopher] "Blue Light" creating capacity for nothing (2007)
___________________________________________________________________
"Blue Light" creating capacity for nothing (2007)
Author : Symmetry
Score : 92 points
Date : 2022-12-24 15:06 UTC (3 days ago)
(HTM) web link (theoryofconstraints.blogspot.com)
(TXT) w3m dump (theoryofconstraints.blogspot.com)
| vivegi wrote:
| 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.
| hn_go_brrrrr wrote:
| 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).
| sokoloff wrote:
| What's the thing that adds value to your customer? What is
| the part they're actually paying for?
|
| How much of your time is spent on that thing/those things?
|
| How much is spent on other things and how can you reduce
| that, especially for any resources that are your constrained
| (rate-limiting) resources?
| jancsika wrote:
| Where's the part where the welders start doing needless welding
| to satisfy the helper's target?
|
| Or is the point that a good consultant knows to leave before that
| happens?
| xyzelement wrote:
| 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.
| sitkack wrote:
| > remove stupid/low-skilled work
|
| This is an example of what I mentioned in my other comment.
| sokoloff wrote:
| It is literally stupid work to require them to repeatedly
| suit-up in and later remove PPE in order to another task.
|
| It is low-skilled work to move a part from here to there as
| compared to welding.
|
| These are literally correct and practically useful
| descriptions.
| danuker wrote:
| Many humans avoid malicious compliance, because they want to
| keep their job.
| pxx wrote:
| This isn't malicious compliance. This is just what
| organically happens -- see Goodhart's law.
| count wrote:
| More likely the consultant helped them learn that now that
| they're so efficient, they can downsize the welding team.
| D-Coder wrote:
| Or helped them be so efficient that the company didn't go out
| of business.
| mft_ wrote:
| That was my first thought: rather than three or more welders
| welding ~10% of the time, they needed a team of helpers
| setting things up, and a single welder moving quickly from
| job to job...
| LorenPechtel wrote:
| Yup. A welder's helper is a lot cheaper than a welder, not
| to mention all the gear time that produces no value for
| anyone. You want to set things up to the high skill workers
| are as much as possible able to spend their time on the
| high skill task.
| twobitshifter wrote:
| 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 wrote:
| 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
| crdrost wrote:
| 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?").
| hiAndrewQuinn wrote:
| This brought a smile to my face. Solid industrial engineering
| fundamentals brought to the table.
| ChrisMarshallNY wrote:
| This reminds me of the fight I had to hire an Infrastructure
| Engineer (they call them DevOps, these days).
|
| It was like pulling teeth, but, in fairly short order, the chap I
| hired became the most popular member of the team.
| hinkley wrote:
| 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.
| DigiDigiorno wrote:
| Persuasively communicating cost-savings in a budget increase
| request?
|
| I'm so sorry to inform you, but you have management written
| on you.
|
| (But in all seriousness, communication is an important
| management skill, it's good you explained it so directly, but
| ideally a manager would communicate back-and-forth without
| needing to be spoonfed all at once.)
| slowhand09 wrote:
| 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...
|
| Friday is my last day. I am so happy.
| nerdponx wrote:
| 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.
| FredPret wrote:
| 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.
| phyzome wrote:
| There appears to be a typo in the original post title -- perhaps
| s/for/from/?
| [deleted]
| larrydag wrote:
| 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.
|
| https://www.tocinstitute.org/the-goal-summary.html
| sitkack wrote:
| 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.
| xyzelement wrote:
| Can you explain what you mean by "productivity and value
| bigot?"
|
| In my mind productivity and value generation are major
| virtues that benefit the doer and society, big "bigot" has a
| negative connotation and I don't understand how it goes
| together.
| thinkmcfly wrote:
| Like a VC for instance. They are blood sucking leeches upon
| our society
| sitkack wrote:
| Devaluing anything that isn't what the executive considers
| value. One wants optimize systems, not just increase the
| duty cycle of the thing that is expensive. By focusing on
| the only thing that one considers "adding value", the "non-
| value add" tasks and positions become viewed as low
| quality, low skilled and fungible.
|
| The person who fills and jigs the welder's pipeline is just
| as valuable from a systems perspective as the welders.
| matt3D wrote:
| Neglecting the person who fills the jigs will lead to
| less ur time in the long run though.
|
| I'm guessing your issue is not with those that are
| fixated on productivity, but those that are just poorly
| educated in the complexity of how to calculate it.
___________________________________________________________________
(page generated 2022-12-27 23:00 UTC)