Hacker News Reader

Comment by mwexler | Hacker News Reader

Can you explain the last one? What types of communications are you suggesting an arch would avoid?

Otherwise, a very wise list!

Not the OP. However, in my experience, the "tax" of communication is that everything has winners and losers. You can state that the "1+1=2" or "the sky is blue" and someone will lose politically. You have to prepare yourself to defend your position even if 19 out of 20 agree with you; because the one person who disagrees with you has the most to lose.

You can make the feature with one colleague, or you can call in five more people to weigh in and do their parts of the work.

If you involve five more, the result could be better in theory, but it will certainly take MUCH more time because of communication overhead.

Pretalking is highly valuable. Making sure that key stakeholders have an aligned vision and are invested in defending it before opening up a discussion (or dictate, depending on the culture) to a wider audience is necessary. Occasionally expect that the stakeholders and you got it wrong and you'll need to invest time into rebuilding the solution, but, if you're honest with yourselves and diligent, assume that generally the expert subgroup will supply a comprehensive solution.

When I read it, I assumed it meant like network communication in your program. File and network I/O having/being a "tax" makes sense to me.

Completely agree. Had me until the very last point. WTF. Communicate.

The last one is about involving less people. You don't have to read it as "shut up and keep your thoughts for yourself". I read it more like "Do we really need to have six people working on this feature/present in this call?"

well, it needs to be communicated better.

I strongly prefer the phrasing of "When do we actually need to have six people involved on this?" It's often valuable to set a momentum and prune obviously poor decision branches before bringing proposals to a wider audience.

I wonder if they don't mean "between systems".

> Communication is a tax that you should justify before paying it.

I thought it meant like keep things as local as possible. Like within the same process, within the same machine, avoid going through the network because staying on the processor is always the fastest, going to ram is next fastest, and if you need to communicate across the network it is always slowest

I don't think performance advice should be part of a general architectural principles list, so I don't think that's what they meant. Otherwise might as well add "avoid nested loops", etc, and then it devolves into a general programming advice list.

Performance is and always was something dependent on the domain rules. You don't start architecting for performance before understanding requirements so why make it a pillar of all architecture.

Just one more alternative interpretation… I thought it’s about systems calling into other systems, making everything slower, more complicated and brittle…

But maybe it’s about discussing an issue with 10 other people from different teams when it’s not necessary.

But we will never now. I guess OP didn’t want to pay the communication tax on expressing this idea clearly :)

Reply on news.ycombinator.com