Theory-building and why employee churn is lethal to software companies
I&#x27;ve long felt that this is an issue unaddressed by the industry, though I&#x27;ve framed it as &quot;knowledge acquisition and dissemination.&quot; As part of building a software product, the developers acquire deep knowledge of both the problem being solved and the system that solves it. The question then becomes: how do we efficiently capture and disseminate that knowledge?<p>Capturing the knowledge is expensive both initially and over time as the software itself evolves. Disseminating it is expensive because it costs O(NM) time, where N is the number of people receiving the information and M is the average amount of time taken to absorb it. Dissemination is so costly, so we tend to do it in a &quot;lazy&quot; manner, meaning non-strict or as-needed.<p>I think the best software systems I have worked on do a number of things:<p>1. They define enough ad-hoc proofs or invariants via unit tests. It&#x27;s possible to work around these by simply disabling the tests, but, assuming your team hasn&#x27;t devolved to that point, the tests are an excellent source of machine-readable and machine-executable knowledge.<p>2. The software is designed modularly so that one can operate on a part of the system without having to understand the entire system or worry that an unrelated part of the system is going to break.<p>3. The system is kept as simple as possible. The less knowledge one needs to accomplish the same task, the better! This is why KISS is so important. It&#x27;s not for the person writing the code so much as the person debugging it a year later! As a corollary, a simple system tends to have less dependencies. Dependencies are actually costlier than people realize. Every dependency suffers its own bitrot problems and requires knowledge to handle them as part of maintenance.