Coders might have different backgrounds and political opinions, but nearly every one I’ve ever met found deep, almost soulful pleasure in taking something inefficient—even just a little bit slow—and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders’ eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process.
Thompson draws parallels with the capitalist system, and I think he is onto something. The hard-core computer programmer he describes is reminiscent of Israel Kirzner’s description of an entrepreneur as someone who is “alert” to unexploited opportunities for efficiency and profit.
Another Austrian aspect of software development is that production keeps getting more roundabout. Crops are harvested by people using machines that were manufactured by other people who also used machines that were manufactured by. . .Similarly, an new smartphone app uses software already embedded in the phone which in turn uses software in the operating system and software that is embedded in the Internet, etc.
This is a good description of me with regards to bureaucratic process. The psychological drive to do this seems to be something of a inborn personality quirk (or borderline persistent ‘itch’ or obsession) and independent from rationalist motives of personal profit or career advancement or ’empire building’. For me, it is sometimes about that ‘pleasure’, but more often than not, a kind of annoyed irritation at both unnecessary delays and the loss of control over other individuals or entities, which inspired the urge to find ways to bypass them.
To the extent these outside individuals or entities perform a function that is not well-defined, I find that the trade off between substituting with a well-defined and automated process for an increased in the error rate is almost always worth it. Or I should put ‘error’ in scare quotes, because it’s really just a deviation from the (surprisingly wide and inconsistent) distribution of human responses, which is necessarily hard to assess for fault rate, but which I suspect is not, in reality, that much better, and often hard to justify in terms of additional cost and delay.
There is indeed vast potential for efficiencies in bureaucracy, and my experience is that talk of internal resistance is greatly exaggerated. Mostly, few people in positions to do anything about it have any concrete motivation to do so, and even the few quirky individuals like me who just can’t help themselves often lack the means and authority to pull it off.
My impression is that it is much more a matter of improving organization capital as it is the use of new IT. For anything that actually has to get done fast, there is always a special parallel process that bypasses all the typical sources of unnecessary delay, and indeed, the exception tends to swallow the rule over the long-run, as time is the bottleneck scarce resource for top officials.
James Watt and the steam engine, 1775, is a good example. About the same time, Ben thought the electricity might be a flow, like steam.
After magnetic force, the game has been the same.
Leverage the next generation of Morse’s Law to electrify the current hardware layer. Upon doing that, the advantages of yesterday’s hardware is available in multiplicity, and the ‘stack’ of applications moves up the value chain. The game still being played with the permanent move to 64 bit addressing scheme and dumping 32 bit. There is a huge efficiency gain, as seen in Amazon’s sudden entry and success. The hardware metaphor was retained, since Morse’s time and we direct, two generation linkages, between telegraph and web. I actually had a job once, software transcription from Europe’s, still in use Baudot code, into network digital streams. The actual terminology has been maintained up through Linux, where we still have commands that ‘reverse the motor on the teletype machine’, embedded in some software! CR means jerk the mechanical telegraph key way the frig over to the left with a mechanical jolt. We have an eight bit code for that!
One more.
They used to have telegraph cards for mechanically tapping the telegraph key. These evolved into Hollerith cards for one statement on the computer, paper storage. Stacks of cards were stored in mechanical steel file cabinets. Today we still ‘open file’, it means walk over to the steel cabinet, flip the open lock, use a mechanical key if needed, make sure the person below doesn’t bump your drawer. It is called, fopen, in linux.
The problem with software development (and other things) is that you eventually get sick of the people who raise capital and shake hands taking home 90% of the rewards. It’s personally rewarding at the micro-level but can be very frustrating at the macro-level.
I don’t understand the Austrian obsession with “roundabout” processes. It seems to me that they almost see making processes more roundabout as a goal. I see it as a side effect. If I can make a process more efficient by creating a tool or a program, that’s good, but the goal is efficiency not roundaboutness. If I can make a process or a program more efficient by making it less roundabout, I’ll do that. If anything, less roundabout code tends to be better – that is, more efficient and far easier to understand and maintain.
A computer system is vastly more complex than a steam engine. A mature programmer focuses on robustness first, resource efficiency second and programmer efficiency a close third.
An immature programmer fails to appreciate how easily things can go wrong. P. J. Plauger said that a program should not be at the mercy of its inputs, by which he meant it should be written to handle whatever gets thrown at it without catastrophic failure. This is not at all easy.
In my time in Silicon Valley, the coders were almost all men, most were game players. They all loved to win. The programs are a “puzzle game”, and the puzzle is to take the known but variable input type data, process it in the defined way, and get the known desired output.
When you get it right, you “win”.
My coding was like that, and my friends’ pleasures seemed more like that, too.
Winning by solving the puzzle is a bit different than aesthetically making it more efficient, tho with much overlap.
For production code, “getting it right” by the (already extended once or twice) deadline made the getting it right dominate the elegance of improved efficiency. But we were getting paid based on getting it done fast. When a working kludge is better than a possibly more elegant but not tested alternative method that, at the end of the project, we now think would have been a better way to do it. The original designs usually seemed elegant at the start.