But, when it's that long, do people read it? It seems like a great CYB tactic, but maybe a poor communication tactic. I'm a voracious reader, but when it comes to most corporate communication I won't really read anything over a paragraph long. I might skim it if it is from my manager. Maybe.
Most people will skim the title. Some will read the abstract. Few will read a specific paragraph or two of details. Yet, the writer doesn't know who's going to read what. Could be the writer himself, 6 months down the line. Often times those details are pure gold.
If everyone in a corporation is unwilling to read more than a paragraph of a colleague's thoughts, it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.
> it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.
Honestly, I have seen this happen so many times that I rather suspect it is fairly common.
This however happen exactly when communication is bad. When two people monopolize core, won't explain what they meant by what and effectively make it impossible to split work and effectively work for others. The army of maintainers suggests that original people just move on to new functionality having others fixed their bugs.
It works better when team has mechanism for knowledge sharing and core developers fix their own bugs.
It's hard to have more than 2 developers working on the core of something. Development is a very non-concurrent activity.
Speaking from experience, when there's multiple people trying to take over the same bit, they only create conflicting changes all over the place and deadlock the project. It's worse than if no work was not done. Now somebody needs to take the lead and remerge things manually and discard what cannot be merged.
Regarding maintenance, the later army of maintainers is typically a bunch of contractors mostly sitting idle billing for time. The size of the maintenance team has little correlation to the workload.
It's a lot harder to write something short and concise that efficiently communicates to team members than something long and wordy that requires a lot of reading.
I work on distributed teams that are spread across 10 to 12 time zones. We depend on people making local decisions that are approximately right, because confirming a decision may mean a 24 to 48 hour cycle of back and forth communications.
In these situations it's more important to share "what is the problem" than how to solve it.
