On December 3, I will give a talk on Reflective Thinking at the Scrum Breakfast Zurich.
The abstract goes as follows:
Have you noticed how adopting an Agile process sometimes works and sometimes not? Have you noticed how sometimes nothing changes even though everyone seems to "Inspect and Adapt"?In this talk we try to answer why it so, but laying out a little theory of what we call "reflective thinking". For almost half a century the software engineering community has been working on a theory of reflection, which is defined as "the ability of a system to inspect and adapt itself". We draw parallels with that field and learn several lessons:
- Reflection must be built deep into the organization.
- Reflection always incurs an apparent cost.
- Inspection is easier than adaptation.
- We can only reflect on what is explicit.
- Reflection is a design tool that enables unanticipated evolution.
Reflection is an inherent human ability. Only, it requires explicit training to develop into a capability.
While on holidays in Romania, an old friend, Bogdan Bacila, convinced me to give an interview for the Digi 24 TV station about the Dahl-Nygaard Junior Award that I received this year. This resulted in a piece of news that was broadcasted at the national level, and it was later picked by other news aggregators like Yahoo for Romania.
It was the first time I talked in front of a camera about what I do and that in itself was an educating experience. But, the most interesting part was to observe how messages get picked and how they get transformed.
The interview itself took some 1 hour during which I did my best to explain what I do in laymen terms. However, the TV news slot took about 110 seconds. Obviously, some things had to be compressed.
I had the opportunity of going through the material before it appeared in order to provide my feedback and possible corrections. I did, but at the end that material was again edited at least once by another editor. The result was a highly truncated piece of content.
The message that mattered in the end was that I was the first Romanian to obtain the Dahl-Nygaard award that is one of the most prestigious in the field. This was surprising. I saw myself as the first winner of the award that is not a university professor, but I did not even consider me being the first Romanian to win the award as an important aspect of the matter. Obviously, for the audience it was. And this is what counted.
As for the details, they remain details. For example, the word Junior from Dahl-Nygaard Junior Award was left out, even though it does have a significant meaning for those that know it. For most, the important thing was that the name is mysterious enough to sound important. However, one thing that did make it in the material is that the award is one of the most prestigious and not the most prestigious in the field.
Another thing that was picked out of the several things I said was that I co-founded a research group while in Romania without any resources except from enthusiasm. I mentioned that I started it together with Radu Marinescu and I insisted that his name should be mentioned. Indeed, the longer news piece that came in writing does contain the full name, but the broadcasted one transformed the name of Radu into one of the assistants from Politehnica Timisoara. I found it important for me to not sound as if I would be the center of the universe, and specifically in this case, there was a memory of our common crazy dream of building on top of enthusiasm that I wanted to share and for which I did not want to be the only one to take credit. Yet, from the point of view of the newsmaker and the vast majority of the audience this is just a detail that did not survive.
Even the details about the meaning of my work were compressed to a maximum. Bogdan did a great job summarizing my work as helping engineers from all over the world to understand better what is hidden behind their own lines of code. Note the emphasis on all over the world that makes a difference from the point of view of Romanians. This was completed with me saying that this activity of understanding systems accounts for half of the development budget. 20 seconds. That was all, but I think it does capture the essence.
Interestingly, my opinion about how the research support in Romania has decreased significantly over the last couple of years occupied about the same space. The written news even emphasized that the political environment does have a significant influence on this evolution. This had a controversial nuance to it and it survived almost in full.
All in all, even if there are several things I would still change both in the text and in the images used, the news piece did a reasonable job in particular given the amount of time span. What made me particularly happy was that it ended on a positive note expressing my opinion that Romanians have a great potential, and that students should find and follow the passion in their life. This ending is representative for my thoughts.
Taking a step back, I learnt that seeing how details that I considered important go away can easily turn into sadness. But, if I consider the way the information is being consumed, it is more important to ask what part of the information has the most value for the audience while still being reasonable representative. When it comes to a presentation, everything else is secondary.
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.
This story has to do with my view on what innovation is and how it happens. It also has to do with getting old and having memories to share.
Back in 2002, when I embarked on the PhD journey, I was exposed to a couple of topics. The one that captured my imagination was software evolution analysis. I did not know anything about it, but analyzing time sounded highly philosophical. And it was.
As expected when jumping in a new field, I started by reading papers. After a short while I set myself to implement one of the analyses I encountered. It was about determining the trend of a metric over time. I started typing, but I quickly realized that I was missing a concept to attach time related behavior to. I then went back to searching for papers that would describe what to do, but I could not really find any. So, I built it myself and I called it the history. It turned out that introducing this simple concept many analyses became easier to write, and the idea of modeling history as a first entity became the very center of my thesis.
During the same time, I stumbled across a paper that claimed that one heuristic to follow when understanding a software system is to start from the places that were modified last, the assumption being that these parts will be among those that will need changing next. This bugged me for a while. Somehow I felt like not quite agreeing (there is a story behind how I come to realize that I did not agree with the statement, but we leave it for another time). I was a novice and I could afford to be ignorant.
Thus, I proceeded with implementing an algorithm that would detect the probability of this heuristic. I named it Yesterday’s Weather. I managed to dug up one of the cleaned up versions of my original implementation. I listed it below.
Please, do not read it in details. Just look at it, and continue reading what comes. I promise there is a point.
yesterdayWeatherProbabilityWithTopPreviousWENM: topPreviousWENM
andTopCurrentENM: topCurrentENM
| currentVersions previousClassHistoriesSortedByWENM
yesterdayWeatherHits last2VersionsTopHistories last2Versions
last2HistoriesSortedByENM x valuesCount
previousVersionsTopHistories previousVersionsTopHistoriesNames
over |
currentVersions := OrderedCollection new.
currentVersions addLast: (self allVersionNames at: 1).
yesterdayWeatherHits := 0.
(2 to: self allVersionNames size) do: [: i |
self smelly: 'this algorithm is too big and complex'.
previousClassHistoriesSortedByWENM := (self classHistories
selectFromReferenceVersionCollection: currentVersions)
sortBy: [:a :b | a value getWENM >= b value getWENM].
currentVersions addLast: (self allVersionNames at: i).
previousVersionsTopHistories := OrderedCollection new.
x := previousClassHistoriesSortedByWENM first value getWENM.
valuesCount := 0.
previousClassHistoriesSortedByWENM do: [ :each |
(each value getWENM ~= x) ifTrue: [
valuesCount := valuesCount + 1. x:= each value getWENM].
(valuesCount < topPreviousWENM) ifTrue: [
previousVersionsTopHistories addLast: each]
].
last2VersionsTopHistories := OrderedCollection new.
last2Versions := OrderedCollection new.
last2Versions addLast: (self allVersionNames at: (i-1)).
last2Versions addLast: (self allVersionNames at: i).
last2HistoriesSortedByENM := (self classHistories
selectFromReferenceVersionCollection: last2Versions)
sortBy: [:a :b | a value getWENM >= b value getWENM].
x := last2HistoriesSortedByENM first value getENM.
valuesCount := 0.
last2HistoriesSortedByENM do: [ :each |
(each value getENM ~= x) ifTrue: [
valuesCount := valuesCount + 1. x:= each value getENM].
(valuesCount < topCurrentENM) ifTrue: [
last2VersionsTopHistories addLast: each]
].
previousVersionsTopHistoriesNames :=
previousVersionsTopHistories collect: [ :each |
each value name].
over := false.
last2VersionsTopHistories do: [:each |
((previousVersionsTopHistoriesNames includes:
(each value name)) and: [over not]) ifTrue: [
yesterdayWeatherHits := yesterdayWeatherHits + 1.
over := true].
].
].
^yesterdayWeatherHits/(self size - 1) asFloat.
I applied this algorithm on several systems, and it turned out I was right to doubt the heuristic. It only made sense in some situations. I was thrilled.
Then multiple things happened in a short amount of time.
First, I was highly annoyed by the look of the code. Look at it. Even if it is written in Smalltalk, and Smalltalk is a beautiful language, the code looks terrible. I tried to refactor it, but somehow it did not get better.
Second, I set myself to write a paper about it, when my professors came to me and said: you have to formalize it. "What do you mean?" I asked. "This is an algorithm, so you should be able to explain it to us mathematically," they said. I thought this was unnecessary, in particular given that I was always afraid of strange notations. After all, the code is a formalization in itself, and it does what it is supposed to do.
Finally, I had to give an internal presentation about it. I tried to explain what the algorithm does, but nobody seemed to quite get it. This is what bugged me the most. If they do not get it, why should my other peers?
So, I went back to the drawing board. Not to the code editor. To the drawing board. My target was to try to figure out a way to explain this piece to an outsider by using metaphors and visuals.
And so I did. Yesterday’s Weather boils down to picking a point in the past, and comparing what happened before that point with what happened after that point. More precisely, the original heuristic being that the parts that changed recently are relevant for the near future, we need to check whether those parts that were changed recently also got changed soon after the chosen point in time.
Graphically, it looks like this.
If we step back, what I needed was a simple intersection of two sets: the changed parts from the past and those from the future. So, in the end, the pseudocode looked like this:
YesterdayWeatherHit(present):
past:=all.topChanged(beginning, present)
future:=all.topChanged(present, end)
past.intersect(future).notEmpty()
That’s it. If you apply this algorithm for each version and average the result you get a percentage that reflects the relevance of using the Yesterday’s Weather as a heuristic to predict future changes. You can find more details about the heuristic in the paper. And, yes, it turned out that I was right to doubt the heuristic because it does not necessarily apply to all systems.
Getting back to our story, armed with my new idea, I rewrote my code. It looked like this:
yWFor: yesterdayCheck for: tomorrowCheck
^ ( 3 to: self versions size ) collect: [ :i |
| yesterday tomorrow |
yesterday := self
selectByExpression: yesterdayCheck
appliedFromVersionIndex: 1
toVersionIndexAndPresentInIt: i - 1.
tomorrow := self
selectByExpression: tomorrowCheck
appliedFromVersionIndexAndPresentInIt: i - 1
toVersionIndex: self versions size.
yesterday intersectWith: tomorrow ]
yWFor: yesterdayCheck for: tomorrowCheck
| dailyYW hits |
dailyYW := self detailedYWFor: yesterdayCheck for: tomorrowCheck.
hits := dailyYW sum: [ :each |
each isEmpty
ifTrue: [0]
ifFalse: [1]].
^ hits / (self versions size - 2)
It also turns out that expressing this using a mathematical notation is straightforward, too.
In retrospect, it all seems straightforward. However, it was not as easy as it appears. To get this simple code to work, I had to extend the model with a couple of basic concepts. In the end, this proved to have a conceptual impact as it made the model highly generic. If you are interested in more details, you can read my PhD work.
As exciting as the technical details might be, the essence of the story is not of technical nature. The content was there all along. I could get the computer to compute what I wanted, although in a convoluted way. The main problem was that I could not explain it to other people. It was because of this that I could find what I did not understand. That is right. My understanding was incomplete and I could not explain my intuition. I had to go and rethink what I was doing. Once my ideas got clearer, the explanation got cleaner. In the end, I could explain Yesterday’s Weather in less than 5 minutes. 5 minutes.
My lesson:
Form without content is worthless. Content without form is pointless.
Why pointless? Because without form nobody understands the content, and thus, the package as a whole has no value.
Form is important, but it is often addressed at the end of the process. That’s too late because you will not get it right the first time. You need to test and iterate. And, here is the magic: To test your idea you need the form, and when the form gets clean, the content becomes simple. The act of creation must address both content and form at the same time. This, to me, is at the core of the innovation process.
This semester I have the pleasure of teaching a course on Formale Grundlagen der Informatik at the University of Zürich. The course is targeted at first year students in Computer Science.
As an introduction, I talked about Computational Thinking. The topic for the lecture was inspired by two lectures with the same name by Oscar Nierstrasz (slides download), and by Jeannette Wing (article download).
I set myself to incite the students to look around and see the information and computation behind the functioning of the world. The challenge was to find relevant examples. I struggled for a long time to find them, but somehow I was not satisfied. It was not that I could not find any such examples, but they were not uniform.
I struggled until the day of the lecture, when it finally hit me: If information and computation are so pervasive, it should be straightforward to spot and explain them. I should be able to pick examples at any moment. As a consequence, I challenged myself to put together these examples by documenting the trip from my home (in Bern) to the lecture room (in Zürich). I used my iPhone to take pictures and videos.
I started by telling the students that given that this is the first time I am an official Dozent at the University of Zürich, I wish to mark this day by describing my trip using the pictures I took. I guess they did not understand why this was any relevant for the lecture, but they did laugh. Afterwards, I took exactly the same examples only the second time I described what else can be seen behind the scene. This helped me make the point of the pervasiveness of computational thinking concepts.
I listed below some of the examples I used. The original slides can be found here.
The bus schedule is an example of a data structure made for fast vision-based searching.
The train table is a common resource designed to be read by multiple people in the same time.
People line up in a single queue to buy train tickets from multiple offices.
At the take away shop there are multiple queues for multiple non-conflicting resources.
The vending machine from the train station is a clear example of a state machine.
The instructions of the vending machine form a program that can either be simply read as data, or it can be executed as a program.
During the train trip, the controller checked my ticket. This is also an example of optimistic resource access: you are allowed to use it without any initial check, but get kicked out afterwards if you do not have a valid ticket.
The stack was the most difficult to find. Initially, I looked for it at the free newspaper stand, but as it was afternoon, all newspapers were gone already. I finally found it in the fridge display of a confiserie. I emphasized that one should think twice before buying the last cake from one column, like the chocolate cake on the left which happens to be my favorite.
Finally, the intersection near the University provides a nice example of safety and liveness.