Important concepts in software engineering

1. Important concepts in software engineering The tools to make it “easy to apply common sense”!

2. Concepts • Project time – elapsed time • Supervisor requests – reasonable or out to lunch – how can you determine? • Mistakes, Defects and Errors, which is the worse • What is your code quality? • Why and how do you improve your code quality? • Short group exercise

3. Project Time versus Elapsed Time Student comes to me and says – “ the assignment you gave me was so hard that it took me three weeks to do” The student has lost credibility – does the student really expect me to believe the student spent 12 hours a day each day on my assignment and on nothing else? Make sure you have knowledge of the difference between “project time” and “elapsed time” Project time – the time actually needed to do the project work Elapsed time – the time period that goes by before the student has the time available to put in the “project time” Interrupt time -- the time it takes to get restarted on the project after stopping (to answer the phone, get a coffee). Industry shows that interrupt time is one of the most wasteful things in project development. Question: Would students learn more by taking 6 week rather than 13 week courses?

4. Your supervisor says – I have this idea – when can you get it done by? • You need the ability to be able to estimate how many lines of code a project of this sort would take you to complete (design, code, test, debug, document) • You need to know your average productivity (LOC / hr) • My productivity is about 20 LOC / hr (designed, coded, tested and debugged) • You need to know your other commitments for the week • Now you are in a position to answer your supervisor • DON’T MAKE COMMITMENTS THAT YOU CAN’T MEET • MAKE SURE YOU KNOW HOW TO CALCULATED WHETHER YOU CAN MAKE A COMMITMENT

5. Keep records • Estimating • Do a quick think about a project • Does this seem like a “easy”, reasonably easy, “okay”, “hard but do-able”, “really hard but do-able”, “sort of know what is needed”, “I want a new supervisor” type of project • Lets assume it seems “reasonably easy” – what did “reasonably easy” mean the last time you did a project? -- look at your records • Let assume that is meant 150 LOC (excluding comments and blank lines) • Lets assume productivity is 20 LOC / hr • Calculate project time and elapsed time for the following two students

6. Student one Monday 3 hrs available Tuesday 5 hrs available Wednesday 7 hrs available Student 2 Monday 3 hrs available Tuesday 1.5 hrs available Wednesday 1.5 hrs available Thursday 1.5 hrs available Friday 1.5 hrs available Calculate time when student can deliver

7. Joke about students and programming • Computer engineering conference • All instructors asked “would you get into a ‘fly-by-wire’ aircraft which had all the control software was designed by your students?” • My answer was YES – why?

8. Everybody makes mistakes • Know and understand the following • The ideal development process involves no mistakes • If you can’t have a “mistake-free process” then it is better to have an “error present but defect-free process” than “error-free but defect-present process” • What is a “defect” and what is an “error”?

9. Let’s take an example – TLD rather than TDD (but same idea for TDD) • The student is designing the code for the supervisor • Writes out the design of the code, does a quick “look over” the design and discovers 3 mistakes (which are fixed) but introduces a new mistake (undiscovered). The student does not know it, but there is another undiscovered mistake left in the design • Industry standard 1 new mistake for each mistake fixed • Code – discover 4 mistakes (fixed) – introduces a new one and misses one. Discovers 1 mistake left over from Design • Debug and test – makes 2 new mistakes, fixes both, finds 2 of the missed mistakes from earlier on (the one in design and one from code. Other mistakes are not discovered. • Question – can the student use the information here to “calculate” how many “defects” left after finishing the next project?

10. Mistakes, defects and errors • Mistake – a problem generated • Error – a mistake made during a certain “phase” of the project, and “recognized and fixed” at that stage (phase) of the project • Defect – a mistake that “escaped” a given stage of the project. The longer a defect is goes unrecognized, the bigger problem it is to fixScale by 2 for each phase during which defect is missed

11. Mistakes, defects and errorsAnalysis of code issues • Writes out the design of the code, does a quick “look over” the design and discovers 3 mistakes (which are fixed) but introduces a new mistake (undiscovered). The student does not know it, but there is another undiscovered mistake left in the design • Industry standard 1 new mistake for each mistake fixed

12. Mistakes, defects and errorsAnalysis of code issues • Code – discover 4 mistakes (fixed) – introduces a new one and misses one. Discovers 1 mistake left over from Design

13. Mistakes, defects and errorsAnalysis of code issues Debug and test – makes 2 new mistakes, fixes both, finds 2 of the missed mistakes from earlier on (the one in design and one from code. Other mistakes are not discovered.

14. Defects • Defects are mistakes not found until “after you have left this phase of the project” • More costly the later in the project the are found – scale cost of fixing defects (relative to errors) by 2 ^ number of phases between when the mistake was made and when the defect was found. • The phases here • Design the project, but before writing any code • Writing code (including compiling, assembling and linking) • Debug and test – as soon as you stop writing the code and decide to run the code • Release – once you have decided “the project is finished” and give to the customer

15. Mistakes, defects and errorsAnalysis of code issues Debug and test – makes 2 new mistakes, fixes both, finds 2 of the missed mistakes from earlier on (the one in design and one from code. Other mistakes are not discovered.

16. Mistakes, defects and errorsAnalysis of code issues Customer finds remaining defect after release(You’d be so lucky in real life)

17. You need to know the quality of your process • Modification of the concept of “code quality” taken from Humphrey’s “A discipline of software engineering” Number of Errors Found Quality = 100% * -------------------------------- # Errors + Scaled Defects

18. You need to know the quality of your process Number of Errors Found Quality = 100% * -------------------------------- # Errors + Scaled Defects Quality = 100% * 7 ----- = 38 % 7 + 12

19. Work out your own phases for the way “you” work – collect defect and error information • Consider last student • Recorded defects and errors over last three projects • Code quality was 40%, 60%, 80% • Basic rule – the way you have worked before is the way you are working now, unless you have made an effort to change your process! • The student is working on a new project – much larger than before. • The number of errors is 26 • The scaled defects (found to this point) 35 • How much time should the student spend looking for the remaining defects in the code?

20. Work out your own phases for the way “you” work – collect defect and error information • Code quality was 40%, 60%, 80% = 60% +- 8% • Basic rule – the way you have worked before is the way you are working now, unless you have made an effort to change your process! • The student is working on a new project • The number of errors found is 26 • The scaled defects (found to this point) 14 • How much time should the student spend looking for the remaining defects in the code? • Errors 26 .4 * 2660% = --------------------- = ------------------ X = --------- = 17 Errors + defects 26 + X .6

21. Why improve Quality? • More confidence in your work • More likely to have something to go to a conference in Australia with! • More time to spend on other things • Give two other reasons (personal) for improving quality of your code

22. How do you improve Quality? • Keep track of the errors you make • Do a review • Design review (BEFORE YOU LEAVE THE DESIGN PHRASE) • Code review (BEFORE YOU HIT THE RUN BUTTON • Build tests that you can use now, and use again later when you find you need to modify the code • Make testing easy for yourself – get an automated process • Consider doing some of the code development in a Test driven manner where you design the tests as part of trying to understand what it is you want to do • Try to get tests written before you start coding (TDD) • Only makes sense if you talk to the customer frequently and show incremental builds to the customer to avoid design defects

23. Keep track of the errors you make • For a couple of projects, keep track of all the errors and defects you make • Then take the top five – ignore the others • Develop a process to stop making the top two • Worry about the others later • Find tools to assist you • Talk to others

24. Do a review -- 1 • Design review (BEFORE YOU LEAVE THE DESIGN PHRASE) • Code review (BEFORE YOU HIT THE RUN BUTTON) • Look for the mistakes in the code that “you typically make”; • Don’t look for the mistakes that you don’t typically make • Don’t look for the mistakes that other’s make • Develop a PSP – personal software process

25. Do a review -- 2 • Hints – industry standard • If you don’t review for 25% of the time that you code, pack and go home. Your code is so bad, I can’t rely on you. You spent so much time fixing the bugs in the code that you are wasting my and your time and money. • Don’t review too slowly (slower than 20 LOC / hr) or too quickly (faster than 150 LOC / hr) • Go through the code looking for the first type of error you make, then go through the code for the second. Look for one type of error at a time • NOTE: Scanning over the line you have just typed or the line before COUNTS as a review. • Personally, if I find a mistake in the line I just typed (or the one before), I don’t even count it as a mistake! • On a good day, my error rate can be as low as 80 errors / kLOC. • That’s roughly 1 error for each 10 lines of code • On a recent assignment I was testing, I was very tired and I was making 300 errors / kLOC – and really wasting my time as I was doing no review

26. Share reviews • Rule 1 for finding errors / defects • If you don’t find the error / defect by the third time you read through the code, you will not find it the fourth time or later • Rule 2 – share reviews and problems with a stranger • The stranger could be you – tomorrow or after a coffee break • The stranger could be a “plush toy”. Explaining your problem to the plush toy means that you are explaining to yourself • Rule 3 – team program. • If you and a fellow student are working in a similar area (so you understand the concept), then work together on each other’s project. You discuss, one types, the other reviews, then swap. Then do the same thing for your code • Have penalties. If the reviewer spots an error before the typer does, that’s 25c to the reviewer. However if a defect turns up, that’s $1 to the typer – after all defects are bigger problems than errors

27. Quick brain storm • Groups of around 4 people working with a similar programming language • Excel • C++ or C • MAtlab • Other languages • Each person puts in 5 most common mistakes they make. • Return with a list of the 2 most common mistakes made by the group • Determine what the average productivity is for the group and the range of productivity • Determine what the average code quality is for the group and the range of code quality.

28. Group 1 and 2 results

29. Group 3 and 4 results

30. Group 5 and 6 results

31. Concepts • Project time – elapsed time • Supervisor requests – reasonable or out to lunch – how can you determine? • Mistakes, Defects and Errors, which is the worse • What is your code quality? • Why and how do you improve your code quality? • Short group exercise

32. Further information • Watt Humphreys, “A Discipline of Software Engineering – Personal Software Process” • Dr. Mike Smith – smithmr@ucalgary.ca