Hacker News new | past | comments | ask | show | jobs | submit login

What's a word or phrase to describe this idea/principle?

It feels like the Bruce Lee idea of "take what is useful and leave the rest" but either the opposite or a bastardized version. Like, take what is easy and leave the nuance

I see, whatever this idea/principle would be called, all over.




Or is it "keep the new name and keep doing the old things"?


From what I have seen it's probably more "keep doing the old things + add the name of and a part of some new thing."

Then like evolution, it's survival of the fittest with the entrenched old idea having the heavyweight advantage.

BTW, this is a great point you make! I hope my comment doesn't seem to discount it as your thought made my mind go to the experiences I have seen that led to this comment.


"Implementation without understanding"?


Also known as cargo cult behavior. Taking the visible behavior without the invisible understanding or behind-the-scenes behavior.


I think you nailed it! From the Wiki on 'Cargo cult programming' but I think 'programming' can be subbed out for anything.

> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.

> Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution

> The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position.

https://en.wikipedia.org/wiki/Cargo_cult_programming


Ha! $NEW_JOB instituted "daily scrums" alias "standups" like my second week here where 10 of us sit down in a meeting room for anywhere from 15 to 45 minutes every damned morning to talk about what we did the day before and what we're doing that day. Maybe what we do is ScrumFail? We had no process at all before other than what apparently is not actual waterfall but fits the literal description of a waterfall in that requirements pour down upon us from a tall precipice.


That is a great example of the problem. This is also why I keep trying to get people in my office away from specific practices and big-M Methodologies and focused more on the principles at play.

Why does Kanban help in some offices and do nothing or hurt in others?

Two reasons for success: Luck or understanding. Two reasons for failure: lack of understanding or lack of commitment.

What does Kanban assist with, what principles?

It assists in elaborating and clarifying the workflow or processes in the organization or unit. This can be done many ways, Kanban is just one. But without understanding the, often unwritten, processes you cannot effect meaningful change (at best you're stabbing in the dark).

It also emphasizes focus by setting limits on "work in progress" which improves overall flow/throughput. It turns out that this is, generally, a good idea.

The ones who succeed don't succeed because of Kanban. They succeed because of those two basic principles (and other related principles and concepts that I'm not elaborating on here). Kanban was a mechanism which led to success by drawing on these ideas.

The ones who fail don't fail because of Kanban. They fail because they don't control WIP, or failed to describe their process accurately, so it provided no, or perhaps even negative, value. Why don't they control WIP? Maybe they aren't aware of that element of Kanban, or they don't believe that it can bring value and ignore it. They're too busy fighting fires so they don't have time to focus. Why don't they have an accurate process description? Often, because the process is dictated rather than discovered (You are doing X, even though you actually do A, B, and C).

That's just one practice and two principles that it is related to (there are others). This is the problem with Big-M Methodologies like Big-S Scrum and Big-W Waterfall and Big-A Agile, the easy part is the visible practices. So they're imitated. The hard part is the invisible principles and hidden practices (all the work that went into identifying the workflow, for instance). Repeat this across all the practices in these methodologies and you'll end up with a mess that succeeds by luck, or at least doesn't harm you so badly that you fail, but certainly doesn't offer significant assistance.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: