1. Continuous Improvement

2. Start Simple and Continually Improve E.g., Gmail Labels 1

3. YAGNI (“You aren’t going to need it”) “A design which doesn’t meet business needs is bad, no matter how pretty” “If software is what you want to deliver, then measure progress by how much you have working right now, not by how fancy the design is” 2

4. Rule of the Simplest Design (with Precedence) The system (code + tests) must communicate everything you want to communicate The system must contain no duplicate code The system should have the fewest possible classes The system should have the fewest possible methods 3

5. Identifying Simplest Design Takes Effort Which is simpler: accessing a constructor directly or going through a Factory pattern? Depends on the situation! If get idea like this while writing code, talk it over with programming partner 4

6. Refactoring A program transformation that improve code’s organization, not its function E.g., Renaming variables and methods Gathering duplicate code into methods Splitting long methods into multiple methods 5

7. Benefits of Refactoring Improves maintainability Improves reusability “Prepares” code for new functionality Lets you tidy up existing code by introducing design patterns Lets you separate functionality from form, allowing you to focus on only one at a time 6

8. Long Methods Sometimes method tries to do lots of different things Remember, code should have concern Concern applies to methods, too Usually >= 1 screen of code is too much Most common way of refactoring: 1.Split method into smaller methods 2.Call each method 7

9. Duplicate Code A few lines of code that appear in many different places Often happens during copy-paste coding Usually >= 3 duplicates is too many Most common way of refactoring: 1.Create a new method (and/or new class) 2.Move the duplicate code into the new method 3.Call the new method from each old place 8

10. Large Classes Class that does too many things >= 7 member variables and/or >= 50 methods is too many Most common way to refactoring: 1.Pick the appropriate design pattern 2.Break the class into pieces, using the pattern 3.Fix the code 9

11. Long Parameter Lists Method with many input parameters How is somebody supposed to remember? Most common way of refactoring: 1.Organize some/all parameters into hierarchy, (using composite DP) 2.Pass the composite object, rather than a list of individual values 3.Consider moving methods into the composite class, too 10

12. How to Refactor Correctly Must have working test suite No refactoring allowed until you’ve passed all unit tests Talk with programming partner on how to improve Try out refactoring idea Run unit test Iterate 11

13. Refactor Early and Often Many small refactors easier than single enormous one Each refactoring makes it easier to identify further opportunities 12

14. When to Refactor A new feature seems too difficult to code You created a new feature, but code is difficult to understand You can’t stand to look at your own code You can’t stand to look at your teammate’s code Remember: it’s not your code, it’s your team’s 13

15. Unit Tests == Safety Net When the test suite stops working, it’s unsafe to proceed May let copilot refactor (may have better luck) 14

16. Improving Yourself Use the past to predict the future Once you have completed many software projects You have a lot of information about the past Very little is completely new If the future is like the past, then use past to predict future 15

17. Improving Yourself Be reflective and pay attention to yourself Be disciplined: keep track of your software projects Time to completion Lines of code Evaluate predictions How long did I think it would take? How long did it actually take? 16

18. Improving Yourself E.g., Pair programmers have implemented four web apps: How long should a 30 a.p. web app take to implement? 17 Web app # application points Months required Balloon sales site102 Balloon rides site104 Insurance sales site 206 Find-a-lawyer site103

19. Improving Yourself Personal Software Process (PSP) one way to collect / use data Agile does not prescribe any particular method Whatever method selected should be simple and NOT time consuming 18

20. 19

21. 20

22. Tips for Recording Data Keep a paper or electronic journal while you code Get in the habit of recording start/stop info If you forget, write down an estimate At the end of day, summarize 21

23. Using the Data For making estimates: After received user stories from customer Refer to data when dividing user stories into tasks For refining estimates: Just before you release code to costumer During debrief with team about iteration, refer to data to refine estimates for the next tasks 22

24. Improving Your Team (End of an Iteration) What interesting coding techniques did you discover? What new IDE features did you find? What key problems did you encounter Is one of your teammates really good (or bad) at something? Info used to setup future pairings 23

25. Other Opportunities to Improve Yourself Online tutorials Books Mentors User groups and other clubs Conferences and workshops Programming competitions Volunteering Getting involved with research 24

26. Helpful Online Resources http://www.w3schools.com/ http://www.code.org http://devopsbootcamp.osuosl.org/ – Very useful for learning linux and git and tools http://lug.oregonstate.edu/ – Very useful for learning linux http://www.android.com/ 25

27. Helpful Books Design Patterns by Gamma et al. The Unified Modeling Language User Guide by Booch et al. Problem Frames by Jackson Algorithms by Cormen et al. Contextual Inquiry by Beyer and Holtzblatt Head First series by O’Reilly 26