Video of my talk at NDC Oslo 2015 on "Don't demo facts. Demo stories!"

The talk I gave at NDC Oslo 2015 on Don’t demo facts. Demo stories! is now available online.

Demo-driven innovation CUSO workshop

A couple of weeks ago, I had the pleasure of giving a one-day course to PhD students on the topic of Demo-driven innovation. The course was organized as a CUSO (Conférence universitaire de Suisse occidentale).

I got to work with highly motivated students and argue my way through the demo-driven philosophy.

We started from debating what innovation is and what role it plays in both research and engineering. We agreed that innovation is less about discovering the fantastic, as it is about revealing the obvious.

Then we tackled the problem of the process of research. Finding a complete process to such a complex problem is difficult, but focusing on the most basic problem is a doable first step. We concluded that the most important research challenge is not the fight against nature, but against our own entrenched assumptions.

The argumentation went on: To fight our own assumptions we have to expose them and get feedback. But, feedback comes only from interested people. And it is hard to get people interested in a subject that is not their own. The most effective way to capture the attention and later on the imagination is through stories.

Not fairy tales. Stories. Stories make facts valuable. They capture attention and spark imagination. And the more palpable they are, the better their impact is. In other words, we should strive to demo our story. Especially in a field such as computer science, making stories palpable is both accessible and beneficial.

When demos tell stories, magic things happen. On the one hand, the audience gets more involved. On the other hand, the very implementation of the demo provides a tremendous feedback. We are syntactic creatures, and the look of ideas matters a great deal to us.

And no, there is no such thing as an un-demoable topic.

Humane assessment and demo-driven courses in Oslo - January 19-20, 2015

During January 19-20 I will give two public courses at ProgramUtvikling (the organizers of the NDC conference) in Oslo on:

• Humane assessment primer (January 19)
• Demo-driven innovation (January 20)

The registration forms are available on the above links.

On receiving the Dahl-Nygaard Junior Award and other twists of fate

Recently, AITO (Association Internationale pour les Technologies Objets) announced that I received the Dahl-Nygaard Junior Award for my work on modeling and visualization of evolution and interplay of large numbers of objects.

It’s a great honor for me. And it’s a complete surprise. So much so that when I received the phone call I asked Eric Jul, the president of AITO, if he is sure he called the right person. Go figure.

I did not consider myself in the research game anymore. At least not in the research game I used to play. Since five years I am far from the writing papers business. I participate in program committees only occasionally. I am almost entirely focused on solving concrete engineering problems. I do not even go to academic conferences. And, I am not financed by any research entity either.

I just checked the list of previous recipients, and all of them were/are university professors. Except me. I clearly am not playing that kind of game. Hence the surprise of getting an award for my research contributions.

Talking about contributions, it is humbling to think that my work got through a process of nomination and selection by people I look up to. I had no idea that my work was regarded as meaningful in those circles.

Five years ago, when I left the ivory tower of academia and descended on the muddy industrial soil, I thought that I am leaving the research world. I also thought that the tools and techniques I saw and developed in research should unilaterally enlighten engineers. Little did I know that the mud comes with its own type of beauty without which nothing can grow. Getting my hands dirty was the best research decision I ever made.

I learnt rather painfully that there is a large gap between what researchers typically tackle and what engineers typically need. In essence, none of the tools I was accustomed to were useful for solving the concrete problems I encountered. They were solving somewhat similar problems, but not those I had. As a consequence, I started to build individual solutions. In each situation I applied the one method I knew: the scientific method. I drove decision making through analysis and experimentation. It was almost like during the research time, only this time I did not have to fabricate problems, and I had to deliver working executable solutions.

It was (and still is) both risky and rewarding. The risk came from using methods that were perceived as being unconventional. The reward came from the experiments I did and lessons I could learn. For example, as I built many analysis tools along the way, I noticed that there was no repeatable concrete solution. There were only classes of solutions such as a metric or a visualization, but no concrete metric and visualization had a high repeatable value. This observation led to the development of humane assessment through which I argue that software engineers have to build their own tools.

To validate my claim, I was stubborn enough to only build analysis solutions using Moose. I solved Java problems with a Pharo system. This was rather crazy at the time, but it consistently produced inexpensive solutions. I consequently could show how a proper platform can drive the cost of custom analyses close to zero. And since this worked on other languages, it was only natural to want to have the same power in the one programming language I enjoy. Hence, in the recent years I worked on building a new bread of development tools around Pharo that foster analysis and decrease assessment costs.

It might appear that I did much, but I argue that everyone is building impressive things in their own ways, only without necessarily distilling the lessons into a coherent theory. If I managed to reach any value, it is just because I applied discipline, I allowed myself to dream differently, and I had the patience of letting ideas brew for years. The course of nature did the rest. For example, because I noticed that the act of preparing and giving demos had a significant effect on how I designed systems. After 10 years of looking at this, I could formulate the demo-driven hypothesis and back it up with multiple case studies. I am doing similar experiments now with the influence of reflective principles on organizational design. You can try it, too. You might be surprised at the results.

I am still not sure whether what I do these days is research or just what engineering should be in the first place. Perhaps the distinction is not relevant anymore. Thinking about it I realize now that during my research years, I spent most of my time engineering, while since I am in industry, I spend a significant amount of time researching. We should reconsider the reasons that led to such a deep separation between engineering and research in our field. This chasm tends to make the two worlds artificially incompatible, and this benefits nobody. On the one hand, researchers need concreteness to anchor hypotheses to reality. On the other hand, engineers need to see the conceptual parts of their seemingly boring concrete problems. I can attest both that it is liberating to be exposed to concrete problems, and that there exist at least an interesting facet to any problem.

Working for 12 years around the same kind of projects might look like a tedious journey. Yet, it does not feel long at all. That is because I never worked alone. For the credit granted to me these days, I have to thank all the people that I had the privilege of working with. They aren’t few either. Just take a look at a picture with all those with whom I committed open-source code over a part of my journey (the picture was provided by Yuriy Tymchuk and it shows my commit interactions as seen on smalltalkhub.com until December 2013).

Add those with whom I worked on closed source projects. Add those with whom I interacted in no directly visible way. They all contributed to my evolution. I am lucky enough to be surrounded by brilliant people that make me uncover new inspiring things every day. This is a true gift that I do not take for granted.

The recognition that comes with an award like this one brings with it an overwhelming feeling. Yet, receiving an award is not what kept me going through this journey. Any significant journey can stumble on doubts and be sidetracked by luring paths. I had my share of those, and my inside fire could have not lasted so long without the warm support of my beautiful wife. One smile at a time, she and our joyful kids remind me that we are on an amazing journey whose most exciting part is yet to come.

Change management primer: make it explicit

If you want to change something, give it a name. Make it explicit. Make it a topic of conversation. Be part of the conversation, but let it grow outside of you.

You might be surprised of how much energy you can attract, and how seamless can change happen.