Title. Abstract. Details.

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.

Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.

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.

People read if it’s written well. Don’t make it long to be long, make it long because it needs to be long.

My favorite feedback is when someone replies to a 1000+ word newsletter with “Wow, short and to the point! Thanks”.

> People read if it’s written well.

This is bordering on the No True Scotsman fallacy.

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 didn’t have time to write a short letter, so I wrote a long one instead."

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.