1. The Future of Software Engineering: Tools
Michael Ernst
MIT Lab for Computer Science
[Be excited! Have a twinkle in my eye! This is good research; it is exciting; share the fun I had and enthusiasm I feel.]
[Smile when I make a joke -- don’t be too dry, don’t sound mean.]
[Don’t go too fast through first part of talk.]
[Make eye contact.]
This is a technique for helping programmers to cope with inadequately documented programs.
Invite questions and comments.
Daikon: an Asian radish (not the Asian radish)
Perhaps don’t say this, but this is but a summary: I can’t talk about every aspect of this research, but welcome questions either now or in individual meetings.

2. Tools matter
The most productive people are the most effective tool users
Tools are a change agent

3. Reproducibility Replication is key to the scientific method
Papers may gloss over details
Insist on published systems
Permits additional evaluation
Stop accepting papers without supporting data and implementations
Central repository for such information
Need support for infrastructure-building

4. Counterargument to publication
Responsibility to have commercial impact
Can have commercial impact without IP
If it's a good idea, it will be adopted
Secrecy is antithetical to science & education

5. Evaluation of implementation
Tools should work
for users other than implementers
when run on production systems
Correct the impression that software engineers do not build real systems

6. Evaluation of tools Humans complicate systems
Theorems much easier to understand!
Case studies, not experiments
Devise rewards for reproducing experiments
Special publication venues?
Do not raise the bar for new ideas
Industry can assist academia

7. Ignore the average programmer
Practitioner/researcher gap
What is the job of researchers?
Researchers must assume best practices, in order to have long-term impact

8. Static and dynamic analysis
How to obtain information:
Programmer-supplied
Static analysis: examine the program text
properties are guaranteed to be true
pointers are intractable in practice
Dynamic analysis: run the program
efficient, precise
complementary to static techniques

9. Combining techniques Use static to help dynamic and vice versa
Transfer from one domain to the other
Example: Purify and LCLint
Combine in a principled way
Select the desired efficiency/soundness

10. Lightweight tools No need to produce exact results
Useful results that people can check

11. The return of formal specifications
Full formal specifications do not work
Partial formal specifications:
Specify only certain aspects of behavior
Generated automatically
Other examples from languages and compilers
Example: functional programming

12. Summary Tools are key Publication must include tools Case studies
Assume best practices
Static and dynamic analysis
Lightweight tools