1 Introduction

2 Administrative 70% Exam, 30% Homeworks Must pass exam 4-5 Homeworks Homework grades: 80 is easy, 100 is hard 1-2 Class exercises Lecture in tutorial slot Office hours: by appointment

3 An academic course is limited … We want to emulate Changing requests Partial/Underspecified requests Project is never closed – no end point Large teams Large code base Time factor – human memory is limited Multiple users Multiple versions Wide area – many non-overlapping topics Interfacing with external “things” Lecture time is limited - cannot present complex code Too much code vs. too much explanations

4 Learning this Course Close to social science/literature No formulas, no proofs, no right answer You need to forget a few things Wide but not deep, no linear order Extrapolation: from the simple examples to complex scenarios Requires a different state of mind

5 Our Context OOP Mostly static typing Performance is not issue Things everyone can use You will write slower!

6 Motivation We need to deliver good programs Bugs: results may be catastrophic Project is 95% done, 80% of the time Expensive to change: software is not “soft” (!) In short: programs are complicated Two issues Definition of quality Techniques for achieving quality

7 A One-Line Summary Write test!

8 A Two-Line Summary Rule #1:Write test! Rule #2:Programming is a process of trial-and-error process

9 A Slightly Deeper Summary Rule #1:Write test! Rule #2:Programming is a process of trial-and-error process Rule #3, #4, #5: Turing Church Rule #6: There is no rule #7

10 The Turing & Church Rules A program may contain other programs You cannot know if a program is doing what you expect it to do If it can be done at all, it can be done in many ways

11 Quality in Software ? #bugs in the present #bugs in the future Time to develop Time to add a feature Time to learn the code LOC ? #Users Revenues Conclusions Many contradicting factors Measuring is hard

12 Statistical Correlation Conduct an experiment Measure quality once over a large enough sample Correlate with other properties (that are easier to measure) Similar to clinical trials Candidates for “other properties” Source code metrics, development methodologies, language/technology/tools used Does not work: Expensive Sample size is too small compared to variance Participants must be isolated of new techniques for the duration of the experiment Hidden bugs Conclusion: software metrics are very limited Not surprising: measuring quality seems to be at odds with Turing

13 Burn Charts Time is important. let’s describe our progress vs. time Vertical axis: tasks completed Horizontal axis: time line

14 Burn Up

15 Burn Up Example

16 Quality in Software High-quality: A software whose burn curve is linear Similar to Big-O notation of algorithms Does not distinguish between two linear curves Differences in domain, languages, … States that a flattening is the #1 risk Can be experienced even in student assignments Result oriented Unlike code metrics whose correlation with the net result is indirect (at best) Requires constant feedback, short iterations Past is measurable Provides some confidence for the future

17 Achieving Linear Burn Up The reason why people are obsessed with design A good design => High quality Two questions What is design? How can one achieve good design?

18

19 (Intelligent) Code Review Context Schedule considerations Criticality Legacy Not all parts of a program should be of the same quality Readability “Code is for communication” Code is read more than written

20 What is Design (I) Sufficient information for a craftsman of typical skill to be able the build the artifact without excessive creativity. (Guy Steele)

21 public class Calculator { int x; public A(int n) { x = n; } public int add(int y) { return x + y; } public int sub(int y) { return x – y; } }

22 Using a Calculator Object Compute 5 + 9, put result in x int x = 5 + 9; int x = new Calculator(5).add(9); Protocols induce a new programming language

23 Class IndentingPrinter public class IndentingPrinter { private String indentation = ""; private final StringBuilder sb = new StringBuilder(); public void inside() { indentation += " "; } public void outside() { indentation = indentation.substring(2); } public void print(String s) { sb.append(indentation).append(s).append('\n'); public String toString() { return sb.toString(); } }

24 Using IndentingPrinter’s Language public class Book { private String name; public Book(String name) { this.name = name; } public void print(IndentingPrinter p) { p.print("Book: " + name); } } public class Library { private String name; private List books = new ArrayList (); public Library(String name) { this.name = name; } public void add(Book b) { books.add(b); } public void print(IndentingPrinter p) { p.print("Library: " + name); for (Book b : books) b.print(p); }

25 Class IndentingPrinter (II) public static class IndentingPrinter { private final String indentation; private StringBuilder sb = new StringBuilder(); public IndentingPrinter() { this("", new StringBuilder()); } private IndentingPrinter(String indentation, StringBuilder sb) { this.indentation = indentation; this.sb = sb; } public IndentingPrinter inside() { return new IndentingPrinter(indentation + " ", sb); } public void print(String s) { sb.append(indentation).append(s).append('\n'); public String toString() { return sb.toString(); } }

26 New Protocol => New Language // Book remains the same... public static class Library { private String name; private List books = new ArrayList (); public Library(String name) { this.name = name; } public void add(Book b) { books.add(b); } public void print(IndentingPrinter p) { p.print("Library: " + name); for (Book b : books) b.print(p.inside()); }

27 Which Version do you like better?

28 What is Design (II) Design is the language induced by the protocols of the objects that are available at a certain context

29 “Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another. If you don't understand both sides of an issue, you cannot make an intelligent choice; in fact, if you don't understand all the ramifications of your actions, you're not designing at all. You're stumbling in the dark” Allen Holub, “Why getter and setter methods are evil”,