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.
I watched 1800+ TED talks. I watched all those published on ted.com. Why? Because I am a TED addict. And because each of these talks reminds me that storytelling is essential in everything we do.
Facts are important, but facts alone have no value. They have to be consumed to be worthwhile. Stories make this happen by getting us involved. This applies to researching novel ways, it applies to creating products, it applies to leading people, it applies to educating kids, and it applies to marriage proposals. Essentially, it applies to anything worth doing.
Storytelling is what makes stories happen. But, storytelling is a skill, and like any skill, it can be learnt.
For example, an easy way to learn is to listen to good examples. Like TED talks. But, there are many ways to learn. And, there are even more ways to apply.
It only takes us to invest in it. Why?
Because storytelling is essential.
This year, I participated again at ESUG. As usual, I had great fun and entertaining discussions. As if to make up for my five years absence from the conference, I ended up having quite a busy week, with 3 talks, one tutorial, and the demos from the Innovation Awards.
Here are the recordings of these talks.
Solving real problems with Moose:
Designing for developer experience:
Beacon (lightning talk - it starts at minute 11:00):
Last week, I was at ECOOP in Uppsala to receive the Dahl-Nygaard Junior Award. On that occasion, I had the distinct pleasure of giving a keynote on Software Environmentalism. I do not know about others, but for me it was as emotional and exciting as I thought it would be.
Afterwards, I gave an interview over the phone for a piece of news that appeared on National TV (in Romanian).
It was the first time I gave an interview over the phone, and again it proved to become an educating experience. The main thing I learnt is that the more concise you are, the better chances you have to be quoted in the full. It’s like with tweeting, only in speech. And just like with a good tweet, it’s hard to be concise without preparation.
At the end of July I will have the pleasure of giving a keynote at ECOOP. This is a rare treat, and I intend to enjoy it fully. To make it more exciting, at least for me, I will adventure in wild territories and coin the idea of software environmentalism.
Here is the teaser abstract:
Software systems get larger and larger, and they are being created at an ever increasing rate. While this might appear to be great, we are facing a significant long run problem as we need to assess and recycle them.In fact, the problem is already here: Engineers spend as much as half of the effort on understanding software systems to figure out how to approach subsequent evolutions and the percentage grows with the size and age of the system. In essence, software engineering is more about dealing with existing systems as it is about building systems.
Reverse engineering and program comprehension are established areas that deal with the problem of approaching existing systems. However, in spite of several decades of research and many proposed approaches, the state of practice still shows that, to a large extent, engineers rely on manual code reading as the preferred means to understand the system. The main reason for it is that most existing approaches tend to be generic and ignore the context of systems. This situation does not scale and it should not perpetuate.
We cannot continue to let systems loose in the wild without any concern for how we will deal with them at a later time. Two decades ago, Richard Gabriel coined the idea of software habitability. Indeed, given that engineers spend a significant part of their active life inside software systems, it is desirable for that system to be suitable for humans to live there.
We go further and introduce the concept of software environmentalism as a systematic discipline to pursue and achieve habitability.
Engineers have the right to build upon assessable systems and have the responsibility of producing assessable systems. For example, even if code has often a textual shape, it is not text. The same applies to logs and anything else related to a software system. It’s all data, and data is best dealt with through tools. No system should get away without dedicated tools that help us take it apart and recycle it effectively. For example, every significant object in a system should be allowed to have dedicated inspectors to reveal its various facets and interactions, and every significant library should come with dedicated debugging possibilities.
Who should build those tools? Engineers. This implies that they have to be empowered to do it, and that the cost of building those tools is manageable.
We need to go back to the drawing board to (1) construct moldable development environments that help us drill into the context of systems effectively, (2) reinvent our underlying languages and technologies so that we can build assessable systems all the way down, and (3) reeducate our perception of what software engineering is.