Monthly Archives: May 2014

We Didn’t Mean For It To Turn Out Like This

Looking at the net today, I can’t help but reflect on how it’s turning out so differently than we imagined:

We wanted to exchange information, not play games.

We wanted expected open conversation and idea exchange, not constant drama, anger, and angst.

We wanted insight into the world outside ourselves, not have the world know everything there is to know about us.

We wanted freedom from oppressive governments, not the creation of a new security state.

We expected the web to either be free or paid, not monetized based on how long it could hold our attention.

Browsers were just one way of accessing the net. We expected there to be lots more.

We expected technology to empower us as individuals, not create some kind of hive supermind.

We expected human, face-to-face relationships to be augmented and thrive based on new silicon helpers. We’re finding people staying online and disconnected for most of their lives, texting somebody sitting 10 feet away instead of attempting a conversation.

Man is a social animal evolved to operate semi-autonomously as hunter-gatherers in small tribes. What we are creating is a technological system that is adapting to, emphasizing, and taking advantage all of the weaknesses of the species while not emphasizing our strengths. Another way of saying this is: we’re not getting what we expected, we’re getting what we wanted.

They say that kids growing up in a new system automatically think that system is just the way things are supposed to be. It’s really important to tell this to whoever will listen.

I was there with some of the first commercial users on the net. (Heck, I was on before that, but as a college student I had no idea of what the net was). I was there as developers and content creators started piecing together the future. I was there when Google figured out the ad model, when the average MMORPG gamer was spending 35-hours online each week, when the NSA revelations came out, when Farmville took Facebook by storm. I was there before that. I remember where we were headed.

It wasn’t supposed to turn out like this.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Crazy Idea #4723

I’ve been thinking some lately about Operating Systems, software, functional programming, DevOps, and composable services.

I think they all may be headed for a common future.

Currently, when we want to make things happen, we move between imperative-style coding, where state is scattered all over hell and Georgia, to complicated deploy scenarios, where services talk to each other over all kinds of protocols, to even worse server architectures, where they’re set up once they just kind of grow in place. All of these pieces are moving targets with various versions and constraints. As each layer gets more complicated — the language, the services, the protocols, the architecture — we end up with more and more complex work of keeping all the pieces together and running smoothly.

We’re seeing some patterns. Pure functional programming is composable. Actually, that’s the whole idea: you compose functions into a larger transform. The Unix O/S service model, where you pipe together things like ls, grep, awk, and so forth, is also composable. Composable pieces are scriptable and easily testable; you can “play them back” to verify correctness. In addition, server architectures are also becoming scriptable, where you describe the server architecture in script and then the script builds the platform.

So why not join this all together?

Picture this: A pure FP language where you could either compile the entire code as one piece, or automatically split it up into chunks and deploy separately. You could keep the code in one place and the only thing you’d need to tweak would be the chunking. Want one big app with an input and output? Click this button. Want a dozen apps that talk to each other over a common format? Click that button. Now layer in some DevOps on top of that where certain pieces would talk to other pieces on a schedule, or across a wire, and this format, scheduling, and protocol could be specified in the code (perhaps using attributes). You could meld this into a Puppet/Ansible-style system where not only do you code the solution, but you code the deployment as well.

So you end up with one source file(s), in the same language, that covers app, inter-app-communication, scheduling, and deployment. Learn one system you learn the whole thing. Heck, roll in JS deployment and html while you’re at it. Go back to the days where you coded in one place and the things you coded just ran — you didn’t have to worry about 43 different pieces of complicated wiring spread everywhere.

Ok, now somebody go make that happen :)

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.