DAVE'S LIFE ON HOLD

Building Better Systems: Part 2

Once we acknowledge that the driving force is Political and not technological, we can design our systems to account for this consideration. Rather than design tech that works against beauty and efficiency to solve political problems, we can design our political systems to minimize their impact on the details of our technology. The rule one needs to adopt is design political solutions to political problems, and design technical solutions to technical problems, not technical solutions for political problems.

Take for example the issue of code merging. We have a great many tools which seek to address managing change to code across a distributed group of developers. This is a technical solution to a political problem. Our development strategy requires more than one user to touch the same set of bits. This means that there is no ownership other than a communal one. An individual can not own a file, or else all development surrounding the functionality espoused by that code is dependent on that one person.

But this problem is not a technical one. In a linked language, the computer will associate a symbol table entry for each routine. These symbols could all be versioned and tagged for each individual developer. You could also compile each function as a separate module, or even one library per developer. The technology itself is perfectly capable of linking a version of every developer's work. The problem is not technical, the problem is one of organizing developers and then sharing their work.

Say we replaced all of the source control tools and each published our code to a server. Let's then say we had a build script that could identify, link, and build an arbitrary set of artifacts from these servers and piece together all possible variations of a program. Since we are at it let us also assume that one could build a test suite in the same fashion. So I could mix and match functional units from hundreds of programmers without altering any code.

Did we solve a political problem with this design? Nope! Did we solve a technical problem with this design? Yes. Politically we still need someone to manage the build process and define the test suite. We still need developers to agree to naming conventions and use of shared resources. What we solved was the problem of merging by defining the module level at which a code merge could occur to be the native ABI layer. We still have all of the political problems of what do we do when we want to use code from two programmers with in compatible changes. We have not solved the problem of organizing programmers such that they don't all edit the same logical function. We have done nothing to address the problem of developers missunderstanding or arguing over the shared ontology or design idioms. We did not even solve the problem of code ownership in the final product, merely created a system where by a developer could own their build.

In the end, these problems are political, in that they relate to the organization and relationships between people and their utilization of shared resources. Techological tools can aid in sharing, help identify ownership, and ease the burden of synthesis of the final work output. But they can not solve the human part of the equation.

For a political problem we need political tools.