Good. AND the SA holds an overall vision of what that accounting entails. An "obvious" change in module A may have severe repercussions in module B, which neit

Good. AND the SA holds an overall vision of what that accounting entails. An "obvious" change in module A may have severe repercussions in module B, which neither developers for A nor B may see in a timely manner. Without "code accounting" with a vision - and an informed experienced one at that - 'tis too easy for over-confident short-sighted developers to go crashing through other sections of code, leaving something which may work but degrades performance & maintenance, and which is so pervasive and hard to fix the team must just live with it. AND the holder of that vision must be able to articulate it, in documentation & code & conversation, in a manner which keeps the team cohesive, informed, and upbeat.