My Discoveries of the Year

logoEvery year, the main reason why I go to Devoxx is to discover new stuff. For me it’s all about technology watch. The internet and RSS feeds are my main tech watch instrument but there is one thing that is harder to get through RSS: feelings. Conferences like Devoxx are a unique opportunity, not only to see what’s happening but also to sense how the community is feeling about it, which is at least as important to anticipate on what’s going to be important.

Now you’ve certainly read here and there that there have been a lot of talks about Java EE6 and Closures in JDK 7. There sure were, and there was quite a lot of reactions to those. But frankly, I’m not interested in any of those. I’m not interested in Java EE6 because even though it finally leverages the concepts that have been pushed by the community for so long, the very fact that Sun has been so late in implementing them shows one thing to me: it’s not about them, it’s about us. Sun has been trying to partner with big companies around the JCP, to create a lot of business around those standards. And why were those standards so complex? Because there were so many companies involved in their elaboration? Or was there any interest from those companies to create technologies complicated enough to require a lot of consultants, and books, and trainings, and tools to make things easier? If the first option is true, then how did it happen that a gigantic community of individual software developers made it so that Spring, Hibernate and other Open Source technologies became de facto standards?

Which brings me to the second point I don’t really care about: closures in JDK 7. People have taken matters into their own hands. Other languages have appeared implementing some of the missing features of Java: Scala, Groovy, etc. Some other languages have been imported into the Java landscape, like Ruby and Python. I’ve been using Groovy myself for some time now, and I couldn’t be happier with it. Now Sun is coming after the war, but does it matter? What I see here is that it’s good to have a base language, a base platform. But as soon as you start extending it for purely mercantile reasons, or as soon as you start avoiding certain innovations because you’re afraid it might harm your business or the one of your partners, then things go messy. But once again, the good news is that software gives us power. We developers have the ability not only to decide which technology is better, but to build and promote our own technologies. And I think this is why our world is so dynamic and why things change so fast. What I see here is that languages matter less than our ability to create new ones, to solve more specific problems, to provide some more advanced features. And that strengthens my belief that Language-Oriented Programming is the next big step in the evolution of our technologies.

Now about the things I do care about. My discoveries.

kanbanMy first one is definitely Kanban. I’ve heard about it for quite some time. But I didn’t understand why people were already trying to push it forward, even though we are still fighting to push companies away from waterfall messes. It’s even more radical than Scrum and for that it’s very interesting because it gets closer to what software development really is. The key phrase that kept popping in my head during the 3-hour session about Kanban was “It’s going to take the time it’s going to take.” And that’s why it’s brilliant. Now that I understand Kanban a little better, I see Scrum as a compromise. We’ve taken some of the principles of Lean Manufacturing, we have dissolved them into trusted concepts like RUP’s iterative cycles. And for years, we have been trying to pour that cocktail into their mouth. And in doing that we forgot something important: if they don’t trust us, they will never drink the whole thing, all the more so as it looks weird with all those colors not really mixed together. The way I see it, Lean and Kanban are all about getting back to the basics, and relying on trust. We have to build trust first, we have to make them understand that at least some of us are not interested in building artificial business on top of poor practices. That at least some of us desperately want the software we build to have a real impact on their business. We have to show them our good will so that they let us do our job. And they have to understand that the more they trust us, the faster we will be, the more we will be able to solve other problems. Big software vendors and resource providers will not like that, because every new project comes with its own overhead, because their business thrives on poor practices, stupid methodologies and complex technologies. But once again, power is in our hands, it lies in collaboration, not in corporation.

My second discovery was Spring-Actionscript. Those guys really have a thing to do things in a clever way. Cairngorm, PureMVC, Swiz, they all impose some sort of a structure to your Flex applications, forcing you to surrender some great powers of Flex itself in the process. And here comes Spring-Actionscript, more like a toolbox than a real framework. It doesn’t impose anything. It just gives you all the tools you need, all the glue you miss, to make things fit together perfectly. Their asynchronous abstraction is just brilliant, their configuration options are complete, your code just looks better with it, simpler, more natural. I think that’s what I love most with Spring: not only does it create great technology, but it also instigates a whole pragmatic and elegant way of thinking into the minds of a whole generation of developers, thus encouraging the community to come up with their own technologies: Spring Actionscript used to be called the Prana Framework, developed independently by a Belgian guy who took inspiration in Spring for Java. That’s just awesome. I will definitely integrate Spring Actionscript in a couple of Spring/Flex projects. I think I will even update my todolist sample application with it. Stay tuned.

My third discovery is a couple of technologies to detect and prevent coding errors BEFORE they actually happen. I insist on “before” because of my previous post about TDD: unit tests are all about writing code to check that some other code you have already written (or not written yet) does its job. But to me, this is equivalent to the old prevention versus repression debate. TDD is just repression, and it’s tempting to go there only, because it’s always easier to catch the bad guys than trying to understand why they became bad in the first place. JSR-308 and its pluggable type checkers is all about strengthening the compiler so that it prevents more of the most frequent bugs like NullPointerExceptions. It allows us to make our code more expressive, to give the compiler more information about our intents so that we can prevent bugs from happening. Brilliant! Project Lombok also goes in that direction: it adds a couple of annotations and customizes the Java compiler in order to minimize the amount of boilerplate code we have to type. Once again, by doing so, it improves the expressiveness of the language, allowing us to say more things with less words, thus reducing the likeliness of ambiguities and errors. Awesome! Lombok and type checkers will definitely be part of a couple of projects too. The only thing that really made me uncomfortable with both of these presentations was this question: “Why the hell weren’t those techniques in Java 5 already?”

pomodoroMy fourth and last discovery was Pomodoro technique. Once again, heard of it before, but never dug into it. And then we had this guy with a strange Swedish accent in front of us, playing with dolls, showing us handwritten slides with simplistic drawings. And you could hear the disappointed reaction of a lot of people in the room: “sounds nice, but not applicable to me”. That was my first reaction too. Software development requires long slots of concentration because we need time to load the whole conceptual model of what we’re working on into our mind before being effective, and this implies some overhead. But then when someone asked this very question to the speaker, he answered something like “what if you are loading too much? what if limiting the amount of time you are going to spend on a given task forces you to load just the minimum you need to solve the matter at hand? what if it made you more productive?”. And it made me think: “hmmm… It’s worth a try.” So I will probably try that as well soon.

Overall, this edition of Devoxx was great! The first 2 days, I was somewhat afraid that it would be disappointing, because you could feel that everything was “cheaper”, that there were less sponsors, less schwag, less tempting hostesses. But then the most important part was preserved: amazing independent content and a great community spirit. Finally there was an interesting special guest this year: Twitter. Twitter was everywhere. People were tweeting live from the sessions, there was a projection board with all devoxx-related tweets in the hallway. I and a bunch of my colleagues were even using twitter to cover Devoxx live for our fellow Axenian java developers on our intranet. Twitter was really everywhere this year.

So thanks a lot to Axen for allowing me to go there. Thanks to Stephan and the BeJUG for putting it all together. Thanks to all the great speakers and to my colleagues. This was really a great edition and I can’t wait for the next one.

PS: All the talks will be available in the weeks to com on Parleys.com. So stay tuned.

Text, Expressivity and Culture-Oriented Programming

Following up on my reflexion about what could software development look like a few years or decades from now, there is this big problem that has been bugging me for years now and that I have never found the time to really tackle: expressivity. In the same way as files appear to me as the biggest obstacle to collaboration, I think the main barrier in the way of expressivity is TEXT.

It’s hard to admit, but we’re still building software like cavemen. We don’t have spoken language, just a bunch of noises, we don’t conceptualize much but we do communicate with a few gestures and more importantly some colored drawings on cave walls. The way I see it, we are not much more advanced than that, but it’s normal, software is still relatively young as a discipline and although it has already changed our lives, we have to imagine that it’s just the beginning. And the good news is that we are headed in the right direction.

man

We started off with most elementary way of storing information and communicating with a machine: zeros and ones. Binary. It was too elementary, more like noises coming out of our mouths, so we started to group bits in octets corresponding to hardware instructions and characters. In fact, we added gestures to noises. Then we grouped instructions into statements and procedures, and we designed a way to translate those into the most elementary form of language that machines could understand. We started drawing on walls. But as procedures multiplied like crazy, we needed to conceptualize some more, talking about classes, objects, methods, properties, and so on. Spoken language was born. And with higher level concepts like services, components and multiple programming languages, we added written language. OK, the analogy is not that good, but you get my point: I’m convinced we’re still very early in the overall evolution of communication with machines, and although this evolution is somewhat slow and creates a lot of inertia, I believe that if we want computers to really expand our capabilities (note that I didn’t say “replace us”), we need to go further in abstraction levels.

So what’s next? Binary, assembly, procedural, object-oriented (yes, and functional, if you want), then what? Model-driven? I’ve tried that, it’s just replacing the constraints of text with the constraints of visual representations. It sure makes it easier to conceptualize, but at some point we’re still translating those visual models into text code, which we have to compile. The roundtrip is just too long. What about domain-specific languages? Well, I’m more into that right now. It looks like communicating is naturally based on languages, collections of concepts that relate with one another to describe what a software is and what it does. So focusing on making it easier to define new languages definitely goes in the right direction. That’s why it’s so linked with meta-programming: instead of statically defining layers upon layers of fixed concepts to describe systems with even higher level abstractions, let’s define the root concepts we will use to describe languages that will allow us to describe our systems. That’s why I’m so interested in Groovy at the moment for internal DSLs, although I prefer the more elegant idea of external DSLs and language workbenches, like Jetbrains MPS does.

All of this evolution makes me think of a video I saw recently, that tried to make String theory more accessible:

Let’s say binary is our dimension 0. Assembly is dimension 1: a line. Procedural programming is dimension 2: a plane. Object-Oriented Programming is then 3rd dimension: a volume. And it’s very hard for us to leave it, as it is our most natural way of seeing things. But that’s where I find this explanation of String theory particulary interesting (although not rigorous as some math geek friends of mine pointed out): there starts a cycle. Dimension 4 is a line again, formed by 2 different Object-Oriented Languages, like Java and C++ for example. Still there? Good! That’s where the fun starts: dimension 5 is a plane composed by all the parallel universes that are created by our own choices. Functional programming and OOP can be considered as forming such a plan. Now what if we could design a way to go directly from one of those paradigms to another one, to fold the plane in the 6th dimension: please welcome language-oriented (or meta-) programming! See the cycle? Now most of us are stuck in the 3rd dimension, and some of us are already experiencing the 6th dimension.

So there we are. Seventh dimension is the line joining the set of all possible timelines starting from our software big bang, which is the binary transistor, to another set of possible timelines, starting from another big bang. Quantum computing can be another option, but it’s a hardware one. What about software? Isn’t virtualization a way to forget about the physical hardware? And there we go 8th dimension: going from binary transistors to quantum computing is one line in the seventh dimension. Choosing to go to virtualization instead creates an branching line in the 8th dimension. Which means that if we want to create our ninth dimension, we need to fold the eighth in order to jump from quantum to virtual computing. And that’s where I locate what I call Culture-Oriented Programming. The third stage of the third 3-stage cycle. The final frontier? The next step? Hooooo… my head hurts.

But wait a second, I only talked about computing here. A virtual reality. What if dimension 10 was the line uniting computing with the real world in the purest possible way. Direct communication between human beings and computers. Who said “scary”?

PS: I didn’t intend this post to be so “theoretical”. I only thought with my keyboard and let my imagination go. But I’d love to know what you think about that crazy analogy? Do you think we are limited to 11 dimensions like in string theory?

PPS: That might be my geekiest post EVER!