1. 1 Introduction

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

3. 3 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

4. 4 “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”, http://www.javaworld.com

5. 5 Teaching this Course is Hard 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

6. 6 Learning this Course is Hard Close to social science/literature No formulas No proofs Subjective observations Most notions are not well defined No right answer – many tradeoffs Thought leaders 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

7. 7 On the other Hand… 95% of the material is applicable in 95% of all programming jobs

8. 8 Administrative 70% Exam, 30% Homeworks Must pass exam 4-5 Homeworks Last homework is a team effort Joint grade Homework grades: 80 is easy, 100 is hard Some homework: a fail/pass grade Two class ex. => Must attend No global postponements Reverse order of lecture/tutorial

9. 9 Properties of Programs Have a recursive structure Defined elements can be used to define new elements Non-continuous There’s no guarantee that a program is bug-free If it can be done, it can be done in many ways

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

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

12. 12 Protocol as a Language Compute 5 + 9, put result in x int x = 5 + 9; int x = new A(5).add(9); Protocols induce a new programming language

13. 13 What is Design (II) Design is the language induced by the protocols of the objects that are available in a certain context

14. 14 High Quality Design (interim) A design that Minimizes the number of bugs Minimizes the effort for adding new features

15. 15 Course Plan Week 1 – 3 Introduction, stylistic approaches, basic techniques Week 4 – 5 Regulatory approaches Week 6 – 8 Adaptive approaches Week 9 – 14 Advanced techniques “Approaches” vs. “Techniques” Approaches : chronological order We will group similar approaches together Techniques: difficulty order

16. 16 What will I Gain? You will program slower You will learn cool buzzwords You will be able to compare benefits You will read code better You will write code with less bugs You will programs faster Not teaching how to determine if A is better than B

17. 17 References Richard P. Gabriel Kent Beck Martin Fowler Gang of Four Joel Spolsky Steve Yegge http://www.codinghorror.com http://www.reversim.com http://blog.stackoverflow.com

18. 18 Our Context Every programming is maintenance Feature = change = bug fix OOP Static & Dynamic typing UI, DB, Web-apps Free of charge development Things everyone can adopt within a day Out of scope: RT, Embedded Heavily regulated domains Proprietary development methodologies

19. 19 Characterization of Approaches Philosophy – Assumptions, Ground rules Values – Properties we want to encourage Principles – Generalization of practices Practices – How to achieve the values (Not mandatory)