Opacity — is a top 3 (possibly biggest) fear and burden in terms of figure-things-out-relative-to-cowokers on a localSys. The most effective and direct solution is some form of instrumentation tool for intermediate data. If you develop or master an effective browsing tool, however primitive, it would likely become a competitive advantage in terms of figure-out speed, and consequently earn you some
LocalSys — I feel most of the effective data browser knowledge is localSys knowledge.
If you are serious about your figure-out speed weakness, if you are seriously affected by the opaque issues, then consider investing more time in these browsing tools.
Hard work, but worthwhile.
- eg: Piroz built a Gemfire data browser and it became crucial in the Neoreo project
- #1 eg: in my GS projects, the intermediate data was often written into RDBMS. Also important — input and output data are also written into RDBMS tables. Crucial in everyday trouble-shooting. I rank this as #1 in terms of complexity and value. Also this is my personal first-hand experience
- #2 eg: RTS rebus — during development, I captured lots of output CTF messages as intermediate data… extremely valuable
- Once deployed, QA team relied on some web tools. I didn’t need to debug production issues.
- I remember the static data team save their static data to RDBMS, so they relied on the RDBMS query tool on a daily basis.
Now some negative experiences
- eg: I’m not too sure, but during the Stirt QZ dev projects I didn’t develop enough investigation skill esp. in terms of checking intermediate data.
- eg: in Mvea, we rely on net-admin commands to query order state, flow-element state and specific fills… Not as convenient as a data store. I never became proficient.
- I would say the FIX messages are logged consistently and serve as input and output data browser.
Many projects in my recent past have no such data store. I don’t know if there’s some effective solution to the opacity, but everyone else face the same issue.