Building Better Systems: Part 3

Since we can't solve political problems strictly through technology, and working around political problems through the design of our tools leads to inelegant and ugly hacks, the proper course of action is to hack the people. It you apply the same design principles to the political process itself, you can design political tools to help cope with political problems. By remaining vigilant against conflating technical with political, we can ensure that harmful decisions meant to appease certain people do not adversely affect the majority.

In most of the corporate world, decisions are based primarily upon the perception of value. Most engineers are trained to identify efficient solutions, and incorrectly assume everyone else understands the world in those terms. This misconception is aat the heart of the conflict between the design of elegant systems and what appear to be business objectives. Price is quintessentially independent of cost, what a customer is willing to pay bears little to no relationship to what it actually costs to produce. Each step along the supply chain people set prices they are willing to pay, and providers who can turn a profit at that price point stay in business.

With most software programs, there is a cost to development which looks like:

Time to develop * wage per unit time + capital goods

For any project capable of making money, time becomes the critical factor, and becomes the driving force behind all design decisions. The reasoning is compounded by the more important fact that once software is written it is a commodity, infinitely reproducible at marginal cost. That also means the the shelf life of any software is the difference between time to market and the establishment of a market leader. Perceived value of software is only high until a sufficient number of copy cats create a market. This drives the notion of first mover advantage, and generates the expectation of high percieved value among the executives who think in these terms.

Because the decision is made not on cost but on perceived value, it falls to the system designers to design their part to accommodate this reality. All things being equal, it is not the true cost but the perceived value of time that we need to account for. If you organization devalues people's time, or treats it as a sunk cost or worse free, you have a serious political problem. It means you can not properly discuss the design tradeoffs because the perceived value of your time is low. Likewise if your organization values liquidity over capital improvements the perceived value of the return on your work is also low, and a politically untennable solution.

The same rules apply to the developers working on your system. If a developer places a low valuation on his or her own time, then the quality of work will suffer. If manual effort is preferred over automation, for example, a developer is trading their own time in exchange for lower capital cost. The developer is also contributing to the low perceived value of the executive staff. This means that the lower the perceived value of a developer becomes the less likely they are to be able to push for elegant solutions which save their time.

The primary solution to bad software systems is knowing your part in the value proposition, and ensuring you have the political leverage to shift perceived value among decision makers. It has nothing to do with hacking better tech, but rather hacking the political system in which decisions are made.