The why dimension

Have you ever asked a researcher why she became a researcher.
if she does not want to answer she can always laugh and say: "Why do you ask?"
if she wants to answer, listen. You will learn a lot.

Questions from John Doyle panel at CDC

December 17, 2004 The Bahamas
John Doyle panel.
Our field is so diverse.
Diversity is the common factor, but what is behind the diversity?
Main question: what is the core of control?
What is the common language that many researchers of different fields can find to cooperate?
What is that we should teach to form good ‘control’ people?

Those are good questions.
I hope that here with this BLOG we can find some answers.

Talking at CDC by LG

December 15, 2004 The Bahamas

I am in the hall of the hotel drinking coffee and talking about the blog with some colleagues.
I try to explain again, the purpose of it, asking for stories.

Dimitri Bertsekas told me how he decided to choose our field (decision and control).
He was at MIT and he started in a complete different field , and once while he was in the library he picked a copy of the Ieee Transaction on Automatic Control. He was looking inside when he bumped into Mike Athans pictures. He saw his very smiling and happy face and he decided that a field where people enjoy what they do is what he was looking for.

Munzer Dahleh instead said that it was his brother Mohammed Dahleh that introduced him to control.
After taking his first course in linear algebra as a sophomore and falling in love with the material, Mohammed pointed him to control theory as a possible discipline that he may enjoy particularly due to the extensive linear algebra use.
Munzer loved the abstraction and pedagogy of linear algebra and found that system theory and control poses similar attributes.
This love drove his research interest in his PhD.

Happiness, Enjoyment, Love, and Abstraction have been the basis to become a
Professor at MIT?

The origin of the present blog by Laura

The origin of the present blog has to be found in the past.
I worked as researcher in Politecnico di Torino, where i met Letizia. She was researcher there, too. We were used to talk, talk and talk. Especially during some travel back and forth from Torino to Tuscany.
One of the topic of our conversations was research: the reciprocal need of understanding what the other one was doing for research.
We are in two different areas, she is in computer science and i am in systems and control.
I remember that she was always asking me: but, why are you doing this? what is the reason to do this? What methodology are you using? Who suggested the problem. Are you interested in solving problems that somebody else is giving you or in solutions that can be useful in general. Ans so on.. In what you think to be an expert? Do you think that my interests in software engineering and yours, that actually i do not
get, could have some common point? do you think we can find a common topic of research?
After years of misunderstanding, the friendship was increasing but we still did not really get what the other was doing.
Years went by, i moved to Palermo, she moved to Trondheim, Norway, still trying to find a common topic of research.
Then, we started to reflect more closely on research methods.
She started working on this topic (that was indeed the real topic of our long conversations) and she started teaching some classes for phd students and experts in team.
Finally, i realized that this was the argument i also wanted to investigate, and i
also noticed that in our field none is never talking about research methods.
I realize that to investigate in what is behind what we are doing (research methods..), share experience with others and let the young people and phd students learn by teaching us or teach by learning with us is of fundamental importance for any field.
Now, maybe, i also know that people who are working in different areas, not only have different languages, different background, different aims but also different way to approach problems.
But crossing the boundaries and work in multi-disciplinary or cross-disciplinary or inter-disciplinary fields is also what all my friends seems to be doing now..
Biology, Fluids, Quantum, Data Mining, Internet, just to cite my very close best friends in the control group.
Maybe, you need to start in a field and then you get tired and you start looking around. Maybe is the middle-life crisis.
I still believe that what you should always ask to yourself and let the young ask to themselves is not 'how many papers did i publish last year?'
but 'did i learn something interesting?' 'did i understand what i was doing?'

The end of E3, by Letizia Jaccheri

In 1997, the E3 system was four years old. It has been implemented twice and the last prototype was java based. E3 is java based and still working. But the E3 project died in 1997 when I moved from Torino to Trondheim.

Why did I decide to stop a project, whose results had been published on ACM Transaction on Software Engineering and Methodology? Why did I at the age of 32, give up a project, about which I could have supervised new students? In 1997, I took a lot of decisions. I get married, I get pregnant, I sold the apartment which I had bought renewed in Turin. I left my best friends and a researcher job in Turin. The reason why I did all these choices is a long story, which it would be too long and too simple to explain here.

What is relevant here is that the main reason why I decided to quit E3, was because it belonged to my old life in Turin, and I was not wise enough to understand that E3 and the knowledge I had about process modelling would have supported me. E3 would have been a good old friend, to share with my Norwegian students. I should have let E3 grow and develop.

To tell the truth, I did not "kill" my baby E3 overnight. When I came to Norway, I tried to propose a couple of master theses about E3, but I did not get any students. In 1993, I was invited to teach about E3 at a winter school in Grenoble and I left my 10 months old son, to travel from Norway to France and to teach about process modelling and E3. Each time I talk, or write about software process modelling, I have this feeling that I am talking about something I know and that belongs to me. However, I gave up E3.

The last time I have been talking about E3 at a conference was in 2001, September 2001. I had run a simple experiment in the context of a course, which has been the first software engineering experiment I ever run.

I have never felt home at my Department in Trondheim. When I came, some colleagues started to tell me that I should not work on process issues, but rather on software product issues. Instead of admiring my work in software process modelling, some colleagues of mine pushed me to start working in the software architecture field, as there was that need at the department both on the research and the teaching side.

Now I believe that what I thought was that after changing country, apartment, friends, language, and everything, I could easily change the topic of my research and teaching. But it was not the case.

I am still recognized in Europe for my software process modelling work. Changing to a new big topic as software architecture was not a good idea.

The beginning of the E3 project by Letizia Jaccheri

E3 means Environment for Experimenting and Evolving Software Processes. I have been working at the E3 project for five years. It is in a way ''my'' project, the project of my PhD thesis. I have supervised master students, a couple of PhD students in the context of the E3 projects. Moreover I published a lot about this project. How did E3 start? How and why E3 finish? Which research method did I use? Which were the good and the bad results of the E3 project?

I have been thinking a lot about these questions, and there are many answers. In this story I will focus about the start of E3. Why and how did it start? I have been working in a previous project in the field of software process modeling. Software process modeling is a software engineering subfield which started at the end of the '80. "Software processes are software too" was the title of a paper written by Osterweil. The idea was that one way to solve the software crisis was that of defining precisely the process that practitioners should follow it. The process should be defined so precisely and formally that it was possible to build a machine or a program that could automate it. The process description, or process program, should guide or even enforce the software development process.

At that time, I was thinking that research was not part of my life, nor I was reasoning about the political, social, and ethical consequences of my research. What is perverse is that I have been a programmer myself, I love to consider myself as a creative person, and I would never like to accept to work enforced by a machine. Nevertheless, I had been working in the EPOS project for a couple of years, published papers at conferences and even on the IEEE Transaction on Software Engineering on that topic. The topic was that of finding efficient languages that enable the process manager to define the process in a precise way so that a program can execute them to guide and or enforce the work of programmers.

E3 started as a project to define one of these languages, which should be easier to understand than the ones I have been working with and developed before. Execution was not the main goal. For the relaxation of the property, E3 received a lot of critics at the beginning.
The main reason why I started the E3 project was that Silvano Gai, a professor at Politecnico, encouraged me to do that. I will always be grateful to him for that.