3 ms·

Is it just me, or is the author making a lot of soup from very little meat? E.g., the first bit: > > For example, if you don’t have a backlog of ready commits

Is it just me, or is the author making a lot of soup from very little meat? E.g., the first bit: > > For example, if you don’t have a backlog of ready commits, then speeding up your deploy rate may not be valuable. > Does this mean speeding up deploys to 1 minute is valueless? That’s crazy talk! That looks to me like a blatant straw man. The quoted author said "may", meaning there may well be other reasons that faster deploys is better. And there are, for a different model which the article's author suggests but doesn't bother to explain with the rigor that he's expecting from people talking system dynamics. For any intellectual tool, some people apply it blindly and some put in the work to use it contextually. Can you use SD approaches blindly? Sure. But in my experience it's way less common than the the person using an implicit model (e.g., the tiresome "software is a factory" analogies).

a1369209993 4y ago
While their overall point is valid, they seem to be overly tolerant of straw in the examples they knock down. Eg: > Hale's story misses that the slower pace at large organizations is less about the growing size of the team and more about the growing size and complexity of the codebase and the product. In a Hale-like model, the growing size and complexity of the codebase and the product are communication and contention costs. Unless you wrote the entire codebase yourself (and probably even if you did), you are communicating and contending with the other authors of that codebase, using the codebase itself as a communication medium. Getting rid of other communication and contention costs provides a constant-factor improvement to a process that is still asymtotically quadratic. (Ie, O(a*N^2+b*N^2+...) is still O(N^2) as long as any of a, b, ... are nonzero.)
- twitchard 4y ago
  That's pretty silly. What "shared resources" am I contending with previous developers for? It's not like "oops, I can't deploy to the QA environment now, it's in use by somebody who left in 2015" Also all the remedies he suggests (keeping your responsibility assignment matrix small) would make absolutely no sense if "communication costs" was dominated by the cost of communicating with developers in the past. By any reasonable reading communication costs refers to developers simultaneously working on a task (in analogy to parallel processes).
  - a1369209993 4y ago
    > What "shared resources" am I contending with previous developers for? FTA: > CI takes 30 minutes to run when it used to take 3? Fire everybody, and it'll still take 30 minutes to run. You are contending with them (specifically, the code (tests, etc) they wrote) for CI runtime. The code doesn't go away just because the developer who wrote it is gone. > all the remedies he suggests Are specific to the low-hanging fruit of scenarios that do not include firing every other developer - I wrote "In a Hale-like model" for a reason.
    - twitchard 4y ago
      That's not what resource contention means. Resource contention means two people (or processes) want the same thing and only one can have it at a time.
twitchard 4y ago
This is a fair criticism. I think, if I had stopped at "hey look, Will Larson's model in this post wasn't realistic, this proves there's a bunch of people out there being mystical about system dynamics", this would certainly be a straw man -- but my argument went further. It's "hey look, Will Larson's model in this post wasn't realistic -- in fact, it's impossible to use stock and flow modeling to tell a realistic story about this subject matter, yet nevertheless here is system dynamics being peddled as useful in basically all contexts as a fundamental skill of leadership" which is not a straw man.
- wpietri 4y ago
  It seems to me that it's impossible to tell any realistic story. The point of stories is abstraction such that we can see something non-obvious. "All models are wrong, some models are useful." So to me the appropriate use of SD models is not "perfectly model the vastness we are confronted with", but "find a model we can use for a while to get insights that we can use to try out possible improvements". Stock-and-flow models can indeed do that with software development sometimes. If people are saying that X is the One True Way to Think, yeah, that'd be wrong no matter the X. But from what you wrote, I'm not seeing that.

a1369209993 4y ago

While their overall point is valid, they seem to be overly tolerant of straw in the examples they knock down. Eg: > Hale's story misses that the slower pace at large organizations is less about the growing size of the team and more about the growing size and complexity of the codebase and the product. In a Hale-like model, the growing size and complexity of the codebase and the product are communication and contention costs. Unless you wrote the entire codebase yourself (and probably even if you did), you are communicating and contending with the other authors of that codebase, using the codebase itself as a communication medium. Getting rid of other communication and contention costs provides a constant-factor improvement to a process that is still asymtotically quadratic. (Ie, O(a*N^2+b*N^2+...) is still O(N^2) as long as any of a, b, ... are nonzero.)

twitchard 4y ago
That's pretty silly. What "shared resources" am I contending with previous developers for? It's not like "oops, I can't deploy to the QA environment now, it's in use by somebody who left in 2015" Also all the remedies he suggests (keeping your responsibility assignment matrix small) would make absolutely no sense if "communication costs" was dominated by the cost of communicating with developers in the past. By any reasonable reading communication costs refers to developers simultaneously working on a task (in analogy to parallel processes).
- a1369209993 4y ago
  > What "shared resources" am I contending with previous developers for? FTA: > CI takes 30 minutes to run when it used to take 3? Fire everybody, and it'll still take 30 minutes to run. You are contending with them (specifically, the code (tests, etc) they wrote) for CI runtime. The code doesn't go away just because the developer who wrote it is gone. > all the remedies he suggests Are specific to the low-hanging fruit of scenarios that do not include firing every other developer - I wrote "In a Hale-like model" for a reason.
  - twitchard 4y ago
    That's not what resource contention means. Resource contention means two people (or processes) want the same thing and only one can have it at a time.

twitchard 4y ago

This is a fair criticism. I think, if I had stopped at "hey look, Will Larson's model in this post wasn't realistic, this proves there's a bunch of people out there being mystical about system dynamics", this would certainly be a straw man -- but my argument went further. It's "hey look, Will Larson's model in this post wasn't realistic -- in fact, it's impossible to use stock and flow modeling to tell a realistic story about this subject matter, yet nevertheless here is system dynamics being peddled as useful in basically all contexts as a fundamental skill of leadership" which is not a straw man.

wpietri 4y ago
It seems to me that it's impossible to tell any realistic story. The point of stories is abstraction such that we can see something non-obvious. "All models are wrong, some models are useful." So to me the appropriate use of SD models is not "perfectly model the vastness we are confronted with", but "find a model we can use for a while to get insights that we can use to try out possible improvements". Stock-and-flow models can indeed do that with software development sometimes. If people are saying that X is the One True Way to Think, yeah, that'd be wrong no matter the X. But from what you wrote, I'm not seeing that.