Priorities depend on industry, target users and managers’ experience/preference… Here are my Real answers:
A: instrumentation (non-opaque ) — #1 priority to an early-stage developer, not to a CTO.
Intermediate data store (even binary) is great — files; reliable snoop/capture; MOM
 seldom reliable, due to the inherent nature — logging/capture, even error messages are easily suppressed.
A: predictability — #2 (I don’t prefer the word “reliability”.) related to instrumentation. I hate opaque surprises and intermittent errors like
- GMDS green/red LED
- SSL in Guardian
- thick, opaque libraries like Spring
- Database is rock-solid predictable.
- automation Scripts are often more predictable, but advanced python is not.
(bold answers are good interview answers.)
A: separation of concern, encapsulation.
* any team dev need task breakdown. PWM tech department consists of teams supporting their own systems, which talk to each other on an agreed interface.
* Use proc and views to allow data source internal change without breaking data users (RW)
* ftp, mq, web service, ssh calls, emails between departments
* stable interfaces. Each module’s internals are changeable without breaking client code
* in GS, any change in any module must be done along with other modules’ checkout, otherwise that single release may impact other modules unexpectedly.
A: prod support and easy to learn?
* less support => more dev.
* easy to reproduce prod issues in QA
* easy to debug
* audit trail
* easy to recover
A: extensible and configurable? It often adds complexity and workload. Probably the #1 priority among managers i know on wall st. It’s all about predicting what features users might add.
How about time-to-market? Without testibility, changes take longer to regression-test? That’s pure theory. In trading systems, there’s seldom automated regression testing.
A: testability. I think Chad also liked this a lot. Automated tests are less important to Wall St than other industries.
* each team’s system to be verifiable to help isolate production issues.
* testable interfaces between components. Each interface is relatively easy to test.
A: performance — always one of the most important factors if our system is ever benchmarked in a competition. Benchmark statistics are circulated to everyone.
A: scalability — often needs to be an early design goal.
A: self-service by users? reduce support workload.
* data accessible (R/W) online to authorized users.
A: show strategic improvement to higher management and users. This is how to gain visibility and promotion.
How about data volume? important to eq/fx market data feed, low latency, Google, facebook … but not to my systems so far.