Programmers are like chess players trying to play with a blindfold on — so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself. To “make” a program, you type words. When you want to change the behaviour of the program, be it a game, or a website, or a simulation of physics, what you actually change is a text. 1
Is there a way to build systems differently? Or web apps? Or mobile apps? Or games? Can we feel the behaviour of such systems?
I remember spending my early days as a kid playing with Lego all the time. Lego Technic was one of my favourite, because if you bought more of it, you could build awesome stuff by combining different pieces together. Pieces with holes in them, pneumatic hose kits, pegs, joints, cogs, electric motors, and many many more. Building stuff was a tangible activity and if you wanted to make something new, you could! It boosted your creativity. And also you could test different setups of cogs rotated by electric motor that moved your creation forward or backward or in a ways you wanted — switch the cogs, redesign the pneumatic piping or whatever and your creation could get into a new “state”, not just forward or backward, but also lift something up or down or even rotate the wheels. Whatever you wanted to make (if you had enough pieces that you needed).
I saw the thing. I could touch it. I could physically start and stop the motor by smashing the buttons and see the result of my configuration. But what I couldn’t do was to predict, in real-time, how my system would behave with such configuration and how the behaviour would change after I rearranged the cogs or swapped small pneumatic pipe for a big one.
Few years later, somewhere around 8th or 9th grade, after I thought myself how to create websites (in Notepad), I heard the stories about software developers, sitting in those nice looking buildings, working for large corporations, who programmed in languages out of my reach and understanding at a time. They did their craft in expensive programs so sofisticated that I thought that they can just focus on thinking about how the program should behave and the tool would just fill the blanks with the right code (maybe even speaking back to the programmer). I was naive.
Now I know it’s not that easy. You think about what the program’s behaviour should be and you have to write that code yourself. And it seems that it’s gonna be like that for a while.
But we certainly can think about programs (and systems) differently. Actually, just thinking faster won’t bring the programming revolution. Seeing would.
It’s just the matter of looking at the problem of debugging. Can we step inside our software, physically, and actually see what’s going on? Just like when you bring the car to the service station and the guy there would slide under it and look for the “bug” that’s causing that oil stream pouring behind your car when you drive it. Answer is yes.
Software developers need an immediate connection to what they’re creating. Programming how you know it now, violates this “principle” — that’s why we struggle with tsunami of errors if we’re not disciplined enough. Big systems are also hard to think about because of this. The number of abstractions in it makes it impossible to store everything in programmer’s head.
What we need is new set of tools. Tools that defy conventions, that can help you bend time and space, that can teleport you to the places you know very well but never been able to access and see for yourself, with your plain monkey eyes. Tools that learn and predicts. Tools that will spark the revolution in programming, because it won’t happen on it’s own. Tools that augments the human mind — an extension for your brain through your hands in a symbiosis. It’s not bad to create software yourself, for many people that’s what they love! No need for self-writing programs. I think we don’t even need new programming languages for that.
Can such tools be created? The only answer for such a question is — we have to find out.
 — “The Coming Software Apocalypse”