[btilly]

It is about your skill set, not your title. I have met architects who were unbelievable coders. And ones who were nightmares. But every good architect that I know was also a good programmer. They might or might not actually spend much time programming, but they clearly could do it.

My understanding of the reason is that a good architect needs to be able to mentally connect every level from abstract architecture down to actual code. If you can't, then you'll eventually absorb ideas that sound good but don't really work in practice. (A random example that I dealt with was someone who didn't understand the latency added by sequential RPC round trips. And that the latency gets worse if you're making the mistake of using XML as your on the wire format...) And the failure of said ideas can always be attributed to programmers having screwed up your brilliant architecture.

For the record, this observation about architects is not original to me. I spent a year at Google, and in interview training we were clearly told that Google does not have a position for a non-coding architect. This is not to say that Google does not have positions for architects. http://research.google.com/pubs/jeff.html certainly wears the architect hat well, and is behind the design of large chunks of fundamental Google infrastructure. See http://static.googleusercontent.com/media/research.google.co... for an example of his showing that skillset off. But they have to code. Which Jeff does. A lot.

[goldbrick]

> And that the latency gets worse if you're making the mistake of using XML as your on the wire format...

No it doesn't. That's not what latency is.

[btilly]

Not always, granted, but the format really can matter.

Grabbing a random benchmark, look at http://www.maxondev.com/serialization-performance-comparison.... It is in C#, but every language is going to give similar results. An efficient on the wire format like protocol buffers is a bit faster and a bit smaller than a sane text format like JSON. But XML is several times slower and several times bigger. He didn't test pretty-printing the XML, but that makes it several times slower and bigger still than plain XML.

This adds up sooner than you'd think. For a start there is a noticeable timing difference between an RPC call that fits in one packet and one that has to be split across two.

If you've got an application that spends a sizable portion of its time in serialization/deserialization, it is obvious that the format chosen will affect maximum throughput. (Many distributed applications spend most of their CPU time doing those two things.) It is harder for the format to have a noticeable impact on latency, but it both can and I've seen it happen.