1. Software engineering vs computer science:
2. Empirical software engineering (I):"Software engineering is often treated as a branch of computer science. This is akin to regarding chemical engineering as a branch of chemistry. We need both chemists and chemical engineers but they are very different. Chemists are scientists; chemical engineers are engineers. Software engineering and computer science have the same relationship"
"Assuming that what people do “naturally” must be the right way for people to do things, they (empirical researchers) often draw conclusions about how to do software development from a small number (for example, three) uncontrolled case studies. This results in many publications, but even a large collection of anecdotal reports isn’t enough to scientifically establish knowledge"3. Empirical software engineering (II):
"I was taught that one of the cardinal rules of psychological research is "if you ask a subjet how he/she solves a problem, don't believe what they say". People often do not know how they solve problems, and asking them how they do it often changes the way they work."4. Formal methods:
"It is common for researchers who do not achieve what they set out to achieve to blame the funding. Research in formal methods for software development has been very well funded. More money won’t help; more thinking will"
5. Software maintenance and evolution:
6. Advice for students:"A sign that the Software Engineering profession has matured will be that we lose our preoccupation with the jirst release and focus on the long term health of our products"
"I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date"
7. Research evaluation:
9. The "Star Wars" missile-defense program proposed by Ronald Reagan in the 80s:"The widespread practice of counting publications without reading and judging them is fundamentally flawed for a number of reasons: (a) it encourages superficial research; (b) it encourages overly large groups; (c) it encourages repetition. (d) it encourages small, insignificant studies; (e) it rewards publication of half-baked ideas"8. Research advice:
"The most difficult and crucial step in research is identifying and defining the problem. Successful researchers are usually those who have the insight to find a problem that is both solvable and important"
"I am not a modest man. I believe that I have as sound and broad an understanding of the problems of software engineering as anyone that I know. If you gave me the job of building the system, and all the resources that I wanted, I could not do it. I don’t expect the next 20 years of research to change that fact."10. Modularity:
"To a man with a hammer, everything looks like a nail. To a Computer Scientist, everything looks like a language design problem. Languages and compilers are, in their opinion, the only way to drive an idea into practice.
My early work clearly treated modularisation as a design issue, not a language issue. A module was a work assignment, not a subroutine or other language element. Although some tools could make the job easier, no special tools were needed to use the principal, just discipline and skill.
When language designers caught on to the idea, they assumed that modules had to be subroutines, or collections of subroutines, and introduced unreasonable restrictions on the design. They also spread the false impression that the important thing was to learn the language; in truth, the important thing is to learn how to design and document.
We are still trying to undo the damage caused by the early treatment of modularity as a language issue and, sadly, we still try to do it by inventing languages and tools."
