7 ms·

A big pile of all things of kinds of things. Big Project Complexities - has nothing to do with software business. It's an organization challenge which has been

A big pile of all things of kinds of things. Big Project Complexities - has nothing to do with software business. It's an organization challenge which has been known way before anyone wrote anything remotely complex with software. See planning fallacy, optimism bias, read about how car and structural companies has done it. Look up "GM, Toyota and NUMMI" as an example. Cross Team Dependencies. Again, this is an organizational challenge. Cognitive loads, poor communication structures based on industrial org designs and army-based leadership with control and command. Hierachies etc. Read Fred Brooks and Mel Conway on these for a more specific software approach. Meetings, meetings, meetings. Of course there is a "going around it" solution for this. And it's called a manager. No manager should allow any team member to attend meetings if no thourough agenda is available, no actions for attendees, no proposed actions afterwards and someone who controls the meeting. Meetings will then turn into writing instead of verbal.

ponector 3y ago
Great! Let's schedule a meeting to discuss your thoughts!
punnerud 3y ago
There is also a different way around this; Skip all the meeting and ship code into production, and iterate into good solutions to complex problems based on feedback
- pjc50 3y ago
  > Skip all the meeting and ship code into production This works until you have an outage, disaster, or embarrasment of some kind, at which point everyone is banned from doing that without approval. This leads to a kind of "trauma driven development"; when you suggest a change, you see a flash of fear in the eyes of people around you. If you punish people for improvements often enough, you don't get any improvements.
  - hef19898 3y ago
    Imagine a surgeon would work like this: no prior diagnostics, no procedures to follow, just cut people open and take it from there! Honestly, you shouldn't deploy into production without testing. Development and deployment needs to be tracked and scheduled. Because worst case, it has to be reversible. If you start deploying directly, without coordination with others (skip all the meetings, right?), you are begging for desaster.
    - j4yav 3y ago
      There's always a good case for slowing down and adding more rules. You can even build a whole career out of it, and if you do it right you'll be harder to remove than a tick - simply ensure anything that might threaten you requires your approval and review. Convincing everyone that a mistake deploying software is equivalent to a botched surgery, though, that's a good one! I've not run into that one before but I imagine you could get a lot of mileage out of that at the right company.
      - hef19898 3y ago
        I work in aerospace, last time a company botched software hundreds of people died. Worse than botched surgery. Others rely on whatever software is produced, co-workers, customers, users. I think those people deserve a good quality product. And that requires at least some rules and procedures. Unless, of course, it is a single dev thing. In that case you won't have middle management and performance reviews neither.
        j4yav 3y ago
        I'd be willing to bet that the most recent mistake during a deployment that an aerospace company made didn't result in many people dying. Maybe the last one you read about in the news, but that biases the selection a bit. That said, if you're sending people to the moon, and are actually working on the system that sends them there rather than the website, feel free to have a more rigorous testing procedure. But if you aren't, consider maybe you don't need it.
- Silhouette 3y ago
  ship code into production, and iterate into good solutions to complex problems based on feedback It makes me sad that this is even considered a serious possibility. It implies that as an industry we have so successfully convinced our customers to accept and pay for junk - as if software being junk is somehow normal or inevitable - that making an effort to competently build a good product doesn't generate enough competitive advantage to be a reliable winning strategy.
  - hef19898 3y ago
    Partially, I think, this is due to fast and ubiquotous internet. I remember the days when games were sold on physical media, played single player on a nost of the time offline computer. Same for other software, updates and patches were cumbersome and expensive. Hence, software had to be complete when shipped. Fast forward, today everything can be patched and fixed OTA. It seems that possibility made it possible to ship pre-Beta stuff. That all those OTA updates are an additional revenue stream didn't help.
    - Silhouette 3y ago
      I am absolutely certain you're right. The forcing function to achieve a respectable level of quality before you ship isn't there in an always-online world. The other big factor IMHO is the amount of speculative money that has poured into the industry in recent times. That has allowed a lot of businesses to survive for longer than they naturally could despite shipping junk and that in turn has taught users/customers that expecting better software is unrealistic. Even most unicorn tech businesses (FAANG etc.) still produce a lot of junk and little that is any good - relative to the almost unimaginable scale of resources they have available - because usually they reached that unicorn status by having one or at most a few massive successes that they can defend and that then subsidise all the bad decisions and junk products just as effectively as VC funding rounds.
      - hef19898 3y ago
        Couldn't agree more. We can lament all day long so, it won't change, will it? When it comes to stuff like that, I feel old!
j4yav 3y ago
Alternatively, skip all the meetings anyway and then fire your middle manager. Or, if that fails, go work for a company that values your time.
- hef19898 3y ago
  If you skip all the meetings, your middle manager will fire you and you will have to look for another company.
  - j4yav 3y ago
    Oh no, what will become of my beautiful performance management reviews
    - hef19898 3y ago
      You found a company of more than 5 people without those? Good for you!
      - j4yav 3y ago
        Any company of under 200 with a middle management layer who enforces meeting attendence through the threat of firing and executes a formal performance review process should be considered de facto sociopathic imho.
        hef19898 3y ago
        Counter point: Any employee who refuses to go to meetings and coordinate with others is toxic. Meeting attendence is important, because - others need input or have relevant information to share - activities have to be coordinated - decisions have to be met and shared Getting the balance right is trickey, just not showing up is simply not acceptable so.
        j4yav 3y ago
        Agree to disagree maybe. But consider trying an experiment - take notes so anyone who wasn't there for whatever reason, intentional or not, can read them later, and don't threaten to fire anyone or insult them as being toxic who didn't make it. If you end up in a meeting by yourself, just make a decision and write it down. I'd personally at least be very surprised if all of a sudden you were unable to coordinate activities, make decisions, or share information.
preommr 3y ago
Programmers: Skip the damned meetings! Also programmers: Who and why decided that we should be doing this thing this way?! Or: Why is the other team doing things this way?!
- nine_k 3y ago
  The point is not in not having meetings, but in having useless and inconsequential meetings. It's much like requiring that any computation should either return a value or produce an effect. Without that, it's just waste.
  - klabb3 3y ago
    The problem is that some people, engineers included, think that way more people should be involved in decisions than necessary. One structural cause of that is the “nobody owns anything, everything is shared and employees are replaceable cogs” paradigm. Because then it’s suddenly a real problem that people do things a bit differently. You have to not only agree on what to do (the interface) but also the how (implementation). It would be the same problem in a band if you decided to rotate the instruments every time you jam.
  - chii 3y ago
    > but in having useless and inconsequential meetings. only know to be useless after having had the meeting, and the decisions or discussion were either moot, already known, or completely expected. So how do you know whether a meeting is required, before organizing and/or attending one?
    - mrweasel 3y ago
      A few tricks that can catch meeting that a more or less guaranteed to be useless (in IT): * Does it have less than 10 people attending? * It there an here an agenda? * Is there more technical people than managers? * Do you know why you've been asked to attend? If you can answer "No" to any of those questions, you're going to have a bad time. Now you can have meetings where you answer yes to all of the above, and it's still useless, but the chances are lower.
skeeter2020 3y ago
>> No manager should allow any team member to attend meetings... I say this as a manager: who do you think is scheduling many (or even most) of these meetings?
- Sharlin 3y ago
  Indeed. That’s why the role of the scrum master exists – the thinking goes that because managers can’t be trusted to protect the team from unproductivity due to complicated conflicting interests, you need a "neutral party" to do it instead.

ponector 3y ago

Great! Let's schedule a meeting to discuss your thoughts!

punnerud 3y ago

There is also a different way around this; Skip all the meeting and ship code into production, and iterate into good solutions to complex problems based on feedback

pjc50 3y ago
> Skip all the meeting and ship code into production This works until you have an outage, disaster, or embarrasment of some kind, at which point everyone is banned from doing that without approval. This leads to a kind of "trauma driven development"; when you suggest a change, you see a flash of fear in the eyes of people around you. If you punish people for improvements often enough, you don't get any improvements.
- hef19898 3y ago
  Imagine a surgeon would work like this: no prior diagnostics, no procedures to follow, just cut people open and take it from there! Honestly, you shouldn't deploy into production without testing. Development and deployment needs to be tracked and scheduled. Because worst case, it has to be reversible. If you start deploying directly, without coordination with others (skip all the meetings, right?), you are begging for desaster.
  - j4yav 3y ago
    There's always a good case for slowing down and adding more rules. You can even build a whole career out of it, and if you do it right you'll be harder to remove than a tick - simply ensure anything that might threaten you requires your approval and review. Convincing everyone that a mistake deploying software is equivalent to a botched surgery, though, that's a good one! I've not run into that one before but I imagine you could get a lot of mileage out of that at the right company.
    - hef19898 3y ago
      I work in aerospace, last time a company botched software hundreds of people died. Worse than botched surgery. Others rely on whatever software is produced, co-workers, customers, users. I think those people deserve a good quality product. And that requires at least some rules and procedures. Unless, of course, it is a single dev thing. In that case you won't have middle management and performance reviews neither.
      - j4yav 3y ago
        I'd be willing to bet that the most recent mistake during a deployment that an aerospace company made didn't result in many people dying. Maybe the last one you read about in the news, but that biases the selection a bit. That said, if you're sending people to the moon, and are actually working on the system that sends them there rather than the website, feel free to have a more rigorous testing procedure. But if you aren't, consider maybe you don't need it.
Silhouette 3y ago
ship code into production, and iterate into good solutions to complex problems based on feedback It makes me sad that this is even considered a serious possibility. It implies that as an industry we have so successfully convinced our customers to accept and pay for junk - as if software being junk is somehow normal or inevitable - that making an effort to competently build a good product doesn't generate enough competitive advantage to be a reliable winning strategy.
- hef19898 3y ago
  Partially, I think, this is due to fast and ubiquotous internet. I remember the days when games were sold on physical media, played single player on a nost of the time offline computer. Same for other software, updates and patches were cumbersome and expensive. Hence, software had to be complete when shipped. Fast forward, today everything can be patched and fixed OTA. It seems that possibility made it possible to ship pre-Beta stuff. That all those OTA updates are an additional revenue stream didn't help.
  - Silhouette 3y ago
    I am absolutely certain you're right. The forcing function to achieve a respectable level of quality before you ship isn't there in an always-online world. The other big factor IMHO is the amount of speculative money that has poured into the industry in recent times. That has allowed a lot of businesses to survive for longer than they naturally could despite shipping junk and that in turn has taught users/customers that expecting better software is unrealistic. Even most unicorn tech businesses (FAANG etc.) still produce a lot of junk and little that is any good - relative to the almost unimaginable scale of resources they have available - because usually they reached that unicorn status by having one or at most a few massive successes that they can defend and that then subsidise all the bad decisions and junk products just as effectively as VC funding rounds.
    - hef19898 3y ago
      Couldn't agree more. We can lament all day long so, it won't change, will it? When it comes to stuff like that, I feel old!

j4yav 3y ago

Alternatively, skip all the meetings anyway and then fire your middle manager. Or, if that fails, go work for a company that values your time.

hef19898 3y ago
If you skip all the meetings, your middle manager will fire you and you will have to look for another company.
- j4yav 3y ago
  Oh no, what will become of my beautiful performance management reviews
  - hef19898 3y ago
    You found a company of more than 5 people without those? Good for you!
    - j4yav 3y ago
      Any company of under 200 with a middle management layer who enforces meeting attendence through the threat of firing and executes a formal performance review process should be considered de facto sociopathic imho.
      - hef19898 3y ago
        Counter point: Any employee who refuses to go to meetings and coordinate with others is toxic. Meeting attendence is important, because - others need input or have relevant information to share - activities have to be coordinated - decisions have to be met and shared Getting the balance right is trickey, just not showing up is simply not acceptable so.
        j4yav 3y ago
        Agree to disagree maybe. But consider trying an experiment - take notes so anyone who wasn't there for whatever reason, intentional or not, can read them later, and don't threaten to fire anyone or insult them as being toxic who didn't make it. If you end up in a meeting by yourself, just make a decision and write it down. I'd personally at least be very surprised if all of a sudden you were unable to coordinate activities, make decisions, or share information.

preommr 3y ago

Programmers: Skip the damned meetings! Also programmers: Who and why decided that we should be doing this thing this way?! Or: Why is the other team doing things this way?!

nine_k 3y ago
The point is not in not having meetings, but in having useless and inconsequential meetings. It's much like requiring that any computation should either return a value or produce an effect. Without that, it's just waste.
- klabb3 3y ago
  The problem is that some people, engineers included, think that way more people should be involved in decisions than necessary. One structural cause of that is the “nobody owns anything, everything is shared and employees are replaceable cogs” paradigm. Because then it’s suddenly a real problem that people do things a bit differently. You have to not only agree on what to do (the interface) but also the how (implementation). It would be the same problem in a band if you decided to rotate the instruments every time you jam.
- chii 3y ago
  > but in having useless and inconsequential meetings. only know to be useless after having had the meeting, and the decisions or discussion were either moot, already known, or completely expected. So how do you know whether a meeting is required, before organizing and/or attending one?
  - mrweasel 3y ago
    A few tricks that can catch meeting that a more or less guaranteed to be useless (in IT): * Does it have less than 10 people attending? * It there an here an agenda? * Is there more technical people than managers? * Do you know why you've been asked to attend? If you can answer "No" to any of those questions, you're going to have a bad time. Now you can have meetings where you answer yes to all of the above, and it's still useless, but the chances are lower.

skeeter2020 3y ago

>> No manager should allow any team member to attend meetings... I say this as a manager: who do you think is scheduling many (or even most) of these meetings?

Sharlin 3y ago
Indeed. That’s why the role of the scrum master exists – the thinking goes that because managers can’t be trusted to protect the team from unproductivity due to complicated conflicting interests, you need a "neutral party" to do it instead.