6 ms·

The key insight in this post is in the conclusion section: > My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is tha

by jsd1982 4y ago

The key insight in this post is in the conclusion section: > My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process.

lanstin 4y ago
There is no mistaking the magic when a large group of programmers have a common vision, of sufficient conceptual integrity to allow most anyone to make most any decisions (source: programming in the host side team at AOL while the traffic was still doubling every few months), And yet it is I would say very rare to see a good team scale their vision up. AOL was able to onboard new programmers and share the vision, but we never got a different geographic site converted, not really. One tried things with documentation and two person Webex meetings, and code reviews that focus not on being tidy, but here’s how we understand this problem, these are the reasons to do something, this use case is an example of such and such a concept. (Just a final closing comment, be tidy you won’t be happy otherwise.). It can gradually build up over time, but rarely causes teams to catch fire.
hinkley 4y ago
RPI has a degree in information systems management, I think they call it. A coworker enrolled and worked part time while in the program. Apparently they teach that Conceptual Integrity is the dominant factor in project success or failure. Someone has to be able to fit the entire system in their head and when they go it’s all downhill. Some processes try to break conceptual integrity. Micro services are one but Scrum as practiced usually tries to stick people into a blind valley where the horizon is months out rather than years. That leads to bad minmaxing behaviors, and/or covert channels being used to keep the wheels on. Scrum theater is especially grating when people who make the sausage have to listen to zealous managers brag about how the process is the source of all of their success. Since they don’t know where the success comes from they don’t see it leave the building to be appreciated somewhere else. The second time it was my circus, my clowns, someone had divided the backend and front end people into different groups and it was a shitshow. Until I/we discovered that diagrams of user interactions were less than useless for preventing impedance mismatches between the tiers. What you needed were data flow analyses. Particularly for complex data entry workflows. C comes from B, B comes from A. Rework dropped like a rock once I incorporated this into kickoff meetings.
- BlargMcLarg 4y ago
  It's not even months. People become incredibly risk-averse, need results, see what they want in 2 weeks and instead of the natural process (gain trust, be left to your own devices more), the reins are kept short and any short term mistake is blown out of proportions. Worst is, this has nothing to do with short feedback loops and frequent releases. It all has to do with perception and how the method is used.
  - hinkley 4y ago
    Any time I feel effective in pure scrum, I also feel like I'm an accountant for the mafia; all the bookkeeping is a fiction to keep the authorities happy, meanwhile something completely different is happening in the back room. There's amortizing refactoring across every feature in a module, and there's deep rationalization of why this refactor can plausibly be tied to this ticket. It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in. I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.
    - courgette 4y ago
      I did my best work as in a mafia scrum team. The settings : Giant industrial corporation, giant projects with other giant corps as clients. Process process process. SAFe Scrum. Somehow I ended up in a team that started to care. Like, we, small individual team, had a agenda and a goal. We saw path to success for this mess of a giant project. And we started to shadow work our way thought it. At first myself and another senior guy. As a hobbit. But it became prevalent for the team as a whole to do “prep work” on top of our tickets. We self organize, self train. Why? So we can move faster and actually deliver. Our normal ticket we’re adjacent work. It’s not like we started 30 repo on the side. Finally our scrum master caught on that. She went onboard. We repurposed tickets like nobody’s business. Acceptance criteria was a mere indication, because the QA folks were on board as well. Not to less us merge crap, QA is QA and you don’t go to prod with a buggy industrial system. That shit is dangerous: but they knew where we were going and were fine with changing the AC if they see progress, and if the black market scrum master say we’re gonna have a black market ticket to fix it. We delivered. It fucking worked. My favorite part ? We were the “bad” team. The team without a cool project or a decent backlog. The cleanup crew.
roflyear 4y ago
Yup. It also comes from involving devs in the problems they are trying to solve.
analog31 4y ago
Going even further back, Deming called it "constancy of purpose."

lanstin 4y ago

There is no mistaking the magic when a large group of programmers have a common vision, of sufficient conceptual integrity to allow most anyone to make most any decisions (source: programming in the host side team at AOL while the traffic was still doubling every few months), And yet it is I would say very rare to see a good team scale their vision up. AOL was able to onboard new programmers and share the vision, but we never got a different geographic site converted, not really. One tried things with documentation and two person Webex meetings, and code reviews that focus not on being tidy, but here’s how we understand this problem, these are the reasons to do something, this use case is an example of such and such a concept. (Just a final closing comment, be tidy you won’t be happy otherwise.). It can gradually build up over time, but rarely causes teams to catch fire.

hinkley 4y ago

RPI has a degree in information systems management, I think they call it. A coworker enrolled and worked part time while in the program. Apparently they teach that Conceptual Integrity is the dominant factor in project success or failure. Someone has to be able to fit the entire system in their head and when they go it’s all downhill. Some processes try to break conceptual integrity. Micro services are one but Scrum as practiced usually tries to stick people into a blind valley where the horizon is months out rather than years. That leads to bad minmaxing behaviors, and/or covert channels being used to keep the wheels on. Scrum theater is especially grating when people who make the sausage have to listen to zealous managers brag about how the process is the source of all of their success. Since they don’t know where the success comes from they don’t see it leave the building to be appreciated somewhere else. The second time it was my circus, my clowns, someone had divided the backend and front end people into different groups and it was a shitshow. Until I/we discovered that diagrams of user interactions were less than useless for preventing impedance mismatches between the tiers. What you needed were data flow analyses. Particularly for complex data entry workflows. C comes from B, B comes from A. Rework dropped like a rock once I incorporated this into kickoff meetings.

BlargMcLarg 4y ago
It's not even months. People become incredibly risk-averse, need results, see what they want in 2 weeks and instead of the natural process (gain trust, be left to your own devices more), the reins are kept short and any short term mistake is blown out of proportions. Worst is, this has nothing to do with short feedback loops and frequent releases. It all has to do with perception and how the method is used.
- hinkley 4y ago
  Any time I feel effective in pure scrum, I also feel like I'm an accountant for the mafia; all the bookkeeping is a fiction to keep the authorities happy, meanwhile something completely different is happening in the back room. There's amortizing refactoring across every feature in a module, and there's deep rationalization of why this refactor can plausibly be tied to this ticket. It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in. I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.
  - courgette 4y ago
    I did my best work as in a mafia scrum team. The settings : Giant industrial corporation, giant projects with other giant corps as clients. Process process process. SAFe Scrum. Somehow I ended up in a team that started to care. Like, we, small individual team, had a agenda and a goal. We saw path to success for this mess of a giant project. And we started to shadow work our way thought it. At first myself and another senior guy. As a hobbit. But it became prevalent for the team as a whole to do “prep work” on top of our tickets. We self organize, self train. Why? So we can move faster and actually deliver. Our normal ticket we’re adjacent work. It’s not like we started 30 repo on the side. Finally our scrum master caught on that. She went onboard. We repurposed tickets like nobody’s business. Acceptance criteria was a mere indication, because the QA folks were on board as well. Not to less us merge crap, QA is QA and you don’t go to prod with a buggy industrial system. That shit is dangerous: but they knew where we were going and were fine with changing the AC if they see progress, and if the black market scrum master say we’re gonna have a black market ticket to fix it. We delivered. It fucking worked. My favorite part ? We were the “bad” team. The team without a cool project or a decent backlog. The cleanup crew.

roflyear 4y ago

Yup. It also comes from involving devs in the problems they are trying to solve.

analog31 4y ago

Going even further back, Deming called it "constancy of purpose."