While watching the SLLUG May presentation on SALT by Thomas S. Hatch, I was intrigued by his reference to ØMQ (ZeroMQ). This is a fascinating “intelligent” networking library, but some of the philosophy I found interesting. In the guide it says, for example:
Programming is a science dressed up as art, because most of us don’t understand the physics of software, and it’s rarely if ever taught. The physics of software is not algorithms, data structures, languages and abstractions. These are just tools we make, use, throw away. The real physics of software is the physics of people.
This clicked with me right away. Languages require almost no effort to pick up. Algorithms, etc. are useful toys selected by how well they match the current problem space. The most useful class that I took in university was Computer Theory, the mathematical underpinnings of software, but again it’s a tool.
From the beginning of my software crafting, I intuitively knew that software was about people. Early on I would tell people who approached me, “Write what you think you want, then write what would like in a dream world where anything is possible.” The first list is normally the list constrained by preconceptions of what can and cannot be done. The second list is usually what the client really wants. It’s a great way to trigger discussion on what the real problem space is. And, frequently, many of those items are actually quite feasible.
Code has to talk to code. Code has to be chatty, sociable, well-connected. Code has to run like the human brain, trillions of individual neurons firing off messages to each other, a massively parallel network with no central control, no single point of failure, yet able to solve immensely difficult problems.
I’m sill not convinced about the human brain analogy (a different topic), but I am convinced from my experience that this much is true. Code must talk to code, easily, impromptu, and in unexpected ways… but this hides the greater reality. It is people that drive the whole process. It must be easy for people to arrange the code chatter, and to change it at will to fit the changing needs and desires of individual humans.
While the implementation may show its age, the original Unix model of tiny specialized programs that can be easily threaded together has stood the test of time quite well. The old tools of sed, grep, find, etc. are bits of code that talk to code in a primitive way. Dated they may be, but Un*x and its relatives are the backbone of the Internet.
If you’ve done any work with threads, protocols, or networks, you’ll realize this is pretty much impossible. … Even connecting a few programs across a few sockets is plain nasty, when you start to handle real life situations. Trillions? The cost would be unimaginable. …
Today we face another software crisis, … Only the largest, richest firms can afford to create connected applications. There is a cloud, but it’s proprietary. Our data, our knowledge is disappearing from our personal computers into clouds that we cannot access, cannot compete with. Who owns our social networks? …
[W]hile the Internet offers the potential of massively connected code, the reality is that this is out of reach for most of us, and so, large interesting problems … remain unsolved because there is no way to connect the code, and thus no way to connect the brains that could work together to solve these problems.
Having worked on projects that have tackled pieces of the puzzle, this resonates with me also. Individuals, when left to their own devices to do clever things, can solve this. We have to not buy into the notion that traditional monolithic portals are The One True Way. It’s a seductive ancient paradigm, but software was made for Man. Man was not made for software.
