←back to thread

225 points todsacerdoti | 1 comments | | HN request time: 0.206s | source
Show context
js8 ◴[] No.46184503[source]
What the article suggests is basically Kanban. It's the most effective SW development method, and similar scheduling system (dispatch queue) is used by operating systems in computers. However, management doesn't want Kanban, because they want to promise things to customers.

You can make good estimates, but it takes extra time researching and planning. So you will spend cycles estimating instead of maximizing throughput, and to reduce risk, plan is usually padded up so you lose extra time there according to the Parkinson's law. IME a (big) SW company prefers to spend all these cycles, even though technically it is irrational (that's why we don't do it in the operating systems).

replies(2): >>46185067 #>>46186973 #
greenchair ◴[] No.46186973[source]
Another reason kanban doesn't work for large projects is because you have to coordinate your cycles with multiple dependencies teams roadmaps and releases.
replies(1): >>46189092 #
1. js8 ◴[] No.46189092[source]
I don't think so, only if they need to have a schedule as well. Most OSS projects operate as Kanban and it's just fine.

Waiting on a dependency is kinda like waiting on a lock held by another process in the operating system. It has little bearing on whether dispatch queue is effective or not; in fact, it shows the solution: Do something else instead of waiting. (This is why the OS analogy is so useful for project management, if only PM's would listen!)

It's again, if you need to plan things ahead (for some reason) when the dependencies become a problem.

But maybe I misunderstand what you mean, if you still disagree provide a more specific example.