5 ms·

I was reading https://danluu.com/sounds-easy https://danluu.com/sounds-easy again today, and when reading this article I was reminded of a particular section:

I was reading https://danluu.com/sounds-easy https://danluu.com/sounds-easy again today, and when reading this article I was reminded of a particular section: "Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years" Dan goes on to say: "When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever." Communication scales extremely poorly compared to code and large organizations require a very different skillset than small companies. The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies. There are also good and bad big and small companies. A well run big company is still going to have a large amount of communication overhead vs a small company.

snarf21 4y ago
Well said. I think the key point you make is that we are paid to maximize the value of the business. If the business isn't profitable, we could all lose our jobs. Too many IC feel that if the company isn't maximizing their personal effort they are inefficient and wrong. However, sometimes more value can be added by NOT writing more code or more documents. It is sometimes more valuable to throw away a bunch of completed work and not fall victim to the sunk cost fallacy. Sometimes a "worse" architecture is the highest BV.
- pydry 4y ago
  It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours. We're not all a bunch of mini CEOs.
  - frank_nitti 4y ago
    From what I understood, they are talking about the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting. That doesn’t necessarily mean that the companies were poorly run - larger enterprises with more projects, teams and customers are going to require more meetings. Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.
    - pydry 4y ago
      I tend to find that where the PO/product job doesnt have to be shared with developers the velocity and quality of the product improves considerably. I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant. In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.
    - malort 4y ago
      > the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting The author's complaint was that he only gets to spend 12-25% of his time on these tasks on a good day.
  - __turbobrew__ 4y ago
    In my view the most effective organizations are made up of mini CEOs. When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm https://govleaders.org/rickover.htm
MrBuddyCasino 4y ago
> The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies. I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat. Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.
- sanderjd 4y ago
  It's always a worthy goal to try to improve communication efficiency, but it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in, and have an inflated sense of the importance of the code they're writing (or that they wish they were writing).
  - BlargMcLarg 4y ago
    But that goes for everyone, until you can put it into numbers which aren't gamed. That's what is being challenged here. Do the communication methods as they exist today provide value, and to what degree? Do we have actual numbers? Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.
    - sanderjd 4y ago
      Ironically, trying to measure this better would inevitably require more bureaucracy! It's a good point nonetheless. But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
gone35 4y ago
Don't see how politics or "bickering over the pettiest feature like [...] what colour the chart should be" is what "deliver[ing] maximum business value" is about, as you put it.
- thawaya3113 4y ago
  The amount of energy and time spent on “politics” or “bickering over petty issues” is usually highly overstated by bloggers. It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.
  - janejeon 4y ago
    Eh, it's been causing a lot of issues over a long period of time at least in my workplace, and it's been dragging projects that should've been 2-3 days to 2-3 WEEKS. I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.
Beltiras 4y ago
I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the CEO which will then flesh out what needs to happen in addition to the work done. There will be some iterations of this process until the code can be merged into main and the feature completed. It's not horrible really but it can be way more efficient. I'd really like it if we can move beyond this seat-of-the-pants programming and have a more robust documentation process. I've been a part of feature mills like that, I've built my own products (unsuccessfully business wise) and I've also done contracted work. Out of all of these I was most productive when doing contracted work. I think it was due to the customer having to really spell out all of the things wanted in the work product. The requirements analysis was far better than anything else I've ever touched. I don't know why it should be any less detailed when it concerns your own work. You should beforehand be certain that you know what you are about to build. You should state it in a document. The stakeholders should sign off on it being what they want built. All of this takes time and it should. The engineering part of it is mostly trivial. The hard part is building a consensus on what should be built.
- claytonjy 4y ago
  That description of "pizza-box development" (unfamiliar term for me) sounds pretty good actually? Seems pretty agile: informal planning, time-boxed sprint, revisit with stakeholder, repeat. It gets so much worse when the implementers are further from the stakeholders or customers. What's the issue there? I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter. Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?
  - Beltiras 4y ago
    Buy a pizza for the devs, rip off the lid, sharpie draw the sprint on the lid while eating the pizza.
AndyMcConachie 4y ago
Is there anything new ever written in this space or is everyone just repeating what Fred Brooks said in the 1970s?
hazmazlaz 4y ago
Not sure I understand the thought behind the statement so apologies in advance if I am barking up the wrong tree, but communication scales beautifully in many different contexts. It's almost like a superpower if done right. I do agree though that poor communication does scale extremely poorly if that's what you meant.

snarf21 4y ago

Well said. I think the key point you make is that we are paid to maximize the value of the business. If the business isn't profitable, we could all lose our jobs. Too many IC feel that if the company isn't maximizing their personal effort they are inefficient and wrong. However, sometimes more value can be added by NOT writing more code or more documents. It is sometimes more valuable to throw away a bunch of completed work and not fall victim to the sunk cost fallacy. Sometimes a "worse" architecture is the highest BV.

pydry 4y ago
It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours. We're not all a bunch of mini CEOs.
- frank_nitti 4y ago
  From what I understood, they are talking about the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting. That doesn’t necessarily mean that the companies were poorly run - larger enterprises with more projects, teams and customers are going to require more meetings. Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.
  - pydry 4y ago
    I tend to find that where the PO/product job doesnt have to be shared with developers the velocity and quality of the product improves considerably. I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant. In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.
  - malort 4y ago
    > the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting The author's complaint was that he only gets to spend 12-25% of his time on these tasks on a good day.
- __turbobrew__ 4y ago
  In my view the most effective organizations are made up of mini CEOs. When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm https://govleaders.org/rickover.htm

MrBuddyCasino 4y ago

> The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies. I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat. Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.

sanderjd 4y ago
It's always a worthy goal to try to improve communication efficiency, but it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in, and have an inflated sense of the importance of the code they're writing (or that they wish they were writing).
- BlargMcLarg 4y ago
  But that goes for everyone, until you can put it into numbers which aren't gamed. That's what is being challenged here. Do the communication methods as they exist today provide value, and to what degree? Do we have actual numbers? Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.
  - sanderjd 4y ago
    Ironically, trying to measure this better would inevitably require more bureaucracy! It's a good point nonetheless. But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.

gone35 4y ago

Don't see how politics or "bickering over the pettiest feature like [...] what colour the chart should be" is what "deliver[ing] maximum business value" is about, as you put it.

thawaya3113 4y ago
The amount of energy and time spent on “politics” or “bickering over petty issues” is usually highly overstated by bloggers. It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.
- janejeon 4y ago
  Eh, it's been causing a lot of issues over a long period of time at least in my workplace, and it's been dragging projects that should've been 2-3 days to 2-3 WEEKS. I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.

Beltiras 4y ago

I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the CEO which will then flesh out what needs to happen in addition to the work done. There will be some iterations of this process until the code can be merged into main and the feature completed. It's not horrible really but it can be way more efficient. I'd really like it if we can move beyond this seat-of-the-pants programming and have a more robust documentation process. I've been a part of feature mills like that, I've built my own products (unsuccessfully business wise) and I've also done contracted work. Out of all of these I was most productive when doing contracted work. I think it was due to the customer having to really spell out all of the things wanted in the work product. The requirements analysis was far better than anything else I've ever touched. I don't know why it should be any less detailed when it concerns your own work. You should beforehand be certain that you know what you are about to build. You should state it in a document. The stakeholders should sign off on it being what they want built. All of this takes time and it should. The engineering part of it is mostly trivial. The hard part is building a consensus on what should be built.

claytonjy 4y ago
That description of "pizza-box development" (unfamiliar term for me) sounds pretty good actually? Seems pretty agile: informal planning, time-boxed sprint, revisit with stakeholder, repeat. It gets so much worse when the implementers are further from the stakeholders or customers. What's the issue there? I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter. Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?
- Beltiras 4y ago
  Buy a pizza for the devs, rip off the lid, sharpie draw the sprint on the lid while eating the pizza.

AndyMcConachie 4y ago

Is there anything new ever written in this space or is everyone just repeating what Fred Brooks said in the 1970s?

hazmazlaz 4y ago

Not sure I understand the thought behind the statement so apologies in advance if I am barking up the wrong tree, but communication scales beautifully in many different contexts. It's almost like a superpower if done right. I do agree though that poor communication does scale extremely poorly if that's what you meant.