The Joel Test: 12 Steps to Better Code Emina Torlak - - PowerPoint PPT Presentation

▶
the joel test 12 steps to better code
SMART_READER_LITE
LIVE PREVIEW

The Joel Test: 12 Steps to Better Code Emina Torlak - - PowerPoint PPT Presentation

May 04, 2023 203 likes •805 views

CSE 403: Software Engineering, Spring 2015 courses.cs.washington.edu/courses/cse403/15sp/ The Joel Test: 12 Steps to Better Code Emina Torlak emina@cs.washington.edu Outline 1. Do you use source control? 2. Can you make a build in one

slide-1
SLIDE 1

Emina Torlak

emina@cs.washington.edu

CSE 403: Software Engineering, Spring 2015

courses.cs.washington.edu/courses/cse403/15sp/

The Joel Test: 12 Steps to Better Code

slide-2
SLIDE 2

Outline

2

1. Do you use source control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do you have quiet working conditions? 9. Do you use the best tools money can buy?

  • 10. Do you have testers as part of the team?
  • 11. Do you have interview candidates write code?
  • 12. Do you do hallway usability testing?

www.joelonsoftware.com/ articles/fog0000000043.html

slide-3
SLIDE 3

Outline

2

1. Do you use source control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do you have quiet working conditions? 9. Do you use the best tools money can buy?

  • 10. Do you have testers as part of the team?
  • 11. Do you have interview candidates write code?
  • 12. Do you do hallway usability testing?

Score <= 10 usually means your team is in trouble!

slide-4
SLIDE 4

Outline

2

1. Do you use source control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do you have quiet working conditions? 9. Do you use the best tools money can buy?

  • 10. Do you have testers as part of the team?
  • 11. Do you have interview candidates write code?
  • 12. Do you do hallway usability testing?

Score <= 10 usually means your team is in trouble! 8

slide-5
SLIDE 5

Do you use source control?

3

slide-6
SLIDE 6

Do you use source control?

3

  • Source control …
  • allows multiple developers to collaborate
  • keeps project in consistent state
  • tracks changes and enable roll-back
  • manages multiple versions
  • saves data in case of a disaster
  • is the authoritative source for “daily build”
slide-7
SLIDE 7

Do you use source control?

3

  • Source control …
  • allows multiple developers to collaborate
  • keeps project in consistent state
  • tracks changes and enable roll-back
  • manages multiple versions
  • saves data in case of a disaster
  • is the authoritative source for “daily build”

The ZFR should indicate the state of your repository.

slide-8
SLIDE 8

Can you make a build in one step?

4

slide-9
SLIDE 9

Can you make a build in one step?

4

  • A single script that
  • [does a full checkout from scratch]
  • rebuilds every line of code
  • makes the binary executable files in all versions,

languages and #ifdef combinations

  • [creates the installation package]
  • [creates the final media, web site, …]
slide-10
SLIDE 10

Can you make a build in one step?

4

  • A single script that
  • [does a full checkout from scratch]
  • rebuilds every line of code
  • makes the binary executable files in all versions,

languages and #ifdef combinations

  • [creates the installation package]
  • [creates the final media, web site, …]
  • All steps are automated and exercised regularly
slide-11
SLIDE 11

Can you make a build in one step?

4

  • A single script that
  • [does a full checkout from scratch]
  • rebuilds every line of code
  • makes the binary executable files in all versions,

languages and #ifdef combinations

  • [creates the installation package]
  • [creates the final media, web site, …]
  • All steps are automated and exercised regularly
  • So, why is this valuable?
slide-12
SLIDE 12

Do you make daily builds?

5

slide-13
SLIDE 13

Do you make daily builds?

5

  • Build the entire product every day and run a good

test suite against the new version

  • build from checked in sources
  • automatic and frequent
slide-14
SLIDE 14

Do you make daily builds?

5

  • Build the entire product every day and run a good

test suite against the new version

  • build from checked in sources
  • automatic and frequent
  • Goal: find out early that you’ve got problems and

fix them before disaster strikes

slide-15
SLIDE 15

Do you make daily builds?

5

  • Build the entire product every day and run a good

test suite against the new version

  • build from checked in sources
  • automatic and frequent
  • Goal: find out early that you’ve got problems and

fix them before disaster strikes

  • Benefits
  • minimizes integration risk
  • reduces risk of low quality
  • supports easier defect diagnosis
  • improves morale for developers, managers, customers
slide-16
SLIDE 16

Do you make daily builds?

5

  • Build the entire product every day and run a good

test suite against the new version

  • build from checked in sources
  • automatic and frequent
  • Goal: find out early that you’ve got problems and

fix them before disaster strikes

  • Benefits
  • minimizes integration risk
  • reduces risk of low quality
  • supports easier defect diagnosis
  • improves morale for developers, managers, customers

The ZFR must include your build script or sequence.

slide-17
SLIDE 17

Do you have a bug database?

6

slide-18
SLIDE 18

Do you have a bug database?

6

  • You can’t keep the bug list in your head
  • especially with multiple developers and multiple customers
slide-19
SLIDE 19

Do you have a bug database?

6

  • You can’t keep the bug list in your head
  • especially with multiple developers and multiple customers
  • Moreover, looking at the history of bugs can be insightful!
slide-20
SLIDE 20

Do you have a bug database?

6

  • You can’t keep the bug list in your head
  • especially with multiple developers and multiple customers
  • Moreover, looking at the history of bugs can be insightful!
  • To characterize a bug consider:
  • how to reproduce it
  • expected behavior, actual behavior
  • responsible party, status, priority
slide-21
SLIDE 21

Do you have a bug database?

6

  • You can’t keep the bug list in your head
  • especially with multiple developers and multiple customers
  • Moreover, looking at the history of bugs can be insightful!
  • To characterize a bug consider:
  • how to reproduce it
  • expected behavior, actual behavior
  • responsible party, status, priority
  • Best to use what is integrated with your code hosting.
slide-22
SLIDE 22

Do you have a bug database?

6

  • You can’t keep the bug list in your head
  • especially with multiple developers and multiple customers
  • Moreover, looking at the history of bugs can be insightful!
  • To characterize a bug consider:
  • how to reproduce it
  • expected behavior, actual behavior
  • responsible party, status, priority
  • Best to use what is integrated with your code hosting.

For the beta release assignment, we’ll be asking to see a log of your bugs.

slide-23
SLIDE 23

Do you fix bugs before writing new code?

7

slide-24
SLIDE 24

Do you fix bugs before writing new code?

7

  • Why not fix them later?
slide-25
SLIDE 25

Do you fix bugs before writing new code?

7

  • Why not fix them later?
  • Familiar with the code now
slide-26
SLIDE 26

Do you fix bugs before writing new code?

7

  • Why not fix them later?
  • Familiar with the code now
  • Harder to find (and fix) later
slide-27
SLIDE 27

Do you fix bugs before writing new code?

7

  • Why not fix them later?
  • Familiar with the code now
  • Harder to find (and fix) later
  • Later code may depend on this code (try building on

quicksand…)

slide-28
SLIDE 28

Do you fix bugs before writing new code?

7

  • Why not fix them later?
  • Familiar with the code now
  • Harder to find (and fix) later
  • Later code may depend on this code (try building on

quicksand…)

  • Bugs may reveal fundamental problems
slide-29
SLIDE 29

Do you fix bugs before writing new code?

7

  • Why not fix them later?
  • Familiar with the code now
  • Harder to find (and fix) later
  • Later code may depend on this code (try building on

quicksand…)

  • Bugs may reveal fundamental problems
  • Leaving all bugs to the end will make it harder to

understand and keep the schedule

slide-30
SLIDE 30

Do you have an up-to-date schedule?

8

slide-31
SLIDE 31

Do you have an up-to-date schedule?

8

  • Keeps expectations realistic
  • For the team, customers, stakeholders
slide-32
SLIDE 32

Do you have an up-to-date schedule?

8

  • Keeps expectations realistic
  • For the team, customers, stakeholders
  • Allows for more accuracy
  • Use experience to improve estimates
slide-33
SLIDE 33

Do you have an up-to-date schedule?

8

  • Keeps expectations realistic
  • For the team, customers, stakeholders
  • Allows for more accuracy
  • Use experience to improve estimates
  • Helps prevent feature creep
  • Don’t take on anything without checking the schedule first
slide-34
SLIDE 34

Do you have an up-to-date schedule?

8

  • Keeps expectations realistic
  • For the team, customers, stakeholders
  • Allows for more accuracy
  • Use experience to improve estimates
  • Helps prevent feature creep
  • Don’t take on anything without checking the schedule first

For the SDS, we asked for a schedule. For later releases, we ask you to highlight any changes, and keep all documents up to date.

slide-35
SLIDE 35

Do you have a spec?

9

slide-36
SLIDE 36

Do you have a spec?

9

  • Easier to fix problems at the design stage
slide-37
SLIDE 37

Do you have a spec?

9

  • Easier to fix problems at the design stage
  • You know what you are trying to build
  • So do your teammates and customer
slide-38
SLIDE 38

Do you have a spec?

9

  • Easier to fix problems at the design stage
  • You know what you are trying to build
  • So do your teammates and customer
  • More likely that you build the right thing
  • Pieces fit together
  • Customer is satisfied
slide-39
SLIDE 39

Do you have a spec?

9

  • Easier to fix problems at the design stage
  • You know what you are trying to build
  • So do your teammates and customer
  • More likely that you build the right thing
  • Pieces fit together
  • Customer is satisfied
  • Conceptual integrity for your project
slide-40
SLIDE 40

Do you have a spec?

9

  • Easier to fix problems at the design stage
  • You know what you are trying to build
  • So do your teammates and customer
  • More likely that you build the right thing
  • Pieces fit together
  • Customer is satisfied
  • Conceptual integrity for your project
  • Undocumented code has low value
  • Hard to maintain and to extend
  • Hard to bring new developers on board
slide-41
SLIDE 41

Do you have hallway usability testing?

10

slide-42
SLIDE 42

Do you have hallway usability testing?

10

  • Grab someone in the hallway and make them

use your code

slide-43
SLIDE 43

Do you have hallway usability testing?

10

  • Grab someone in the hallway and make them

use your code

  • Key idea: get feedback fast
slide-44
SLIDE 44

Do you have hallway usability testing?

10

  • Grab someone in the hallway and make them

use your code

  • Key idea: get feedback fast
  • A little feedback now ≫ lots of feedback later
slide-45
SLIDE 45

Do you have hallway usability testing?

10

  • Grab someone in the hallway and make them

use your code

  • Key idea: get feedback fast
  • A little feedback now ≫ lots of feedback later
  • You will get most of the valuable feedback

from the first few users

slide-46
SLIDE 46

Joel’s disclaimer

11

slide-47
SLIDE 47

Joel’s disclaimer

11

  • These are not the only factors that determine success or failure
  • A great team will not help if you are building a product no one wants
  • An incredibly talented team might produce an incredible product

without these guidelines

slide-48
SLIDE 48

Joel’s disclaimer

11

  • These are not the only factors that determine success or failure
  • A great team will not help if you are building a product no one wants
  • An incredibly talented team might produce an incredible product

without these guidelines

  • But all things being equal, these factors indicate a disciplined

team that can consistently deliver

slide-49
SLIDE 49

Joel’s disclaimer

11

  • These are not the only factors that determine success or failure
  • A great team will not help if you are building a product no one wants
  • An incredibly talented team might produce an incredible product

without these guidelines

  • But all things being equal, these factors indicate a disciplined

team that can consistently deliver “The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.”

slide-50
SLIDE 50

Making mission-critical software safe …

12

Gerard J. Holzmann. Mars code, 2014.

slide-51
SLIDE 51

Making mission-critical software safe …

12

  • First, standard precautions for reducing risk in

complex software systems: Gerard J. Holzmann. Mars code, 2014.

slide-52
SLIDE 52

Making mission-critical software safe …

12

  • First, standard precautions for reducing risk in

complex software systems:

  • A good software architecture with a clean

separation of concerns, data hiding, modularity, well-defined interfaces, and strong fault- protection mechanisms.

Gerard J. Holzmann. Mars code, 2014.

slide-53
SLIDE 53

Making mission-critical software safe …

12

  • First, standard precautions for reducing risk in

complex software systems:

  • A good software architecture with a clean

separation of concerns, data hiding, modularity, well-defined interfaces, and strong fault- protection mechanisms.

  • A good development process, with clearly stated

requirements, requirements tracking, daily integration builds, rigorous unit and integration testing, and extensive simulation.

Gerard J. Holzmann. Mars code, 2014.

slide-54
SLIDE 54

Making mission-critical software safe …

13

Gerard J. Holzmann. Mars code, 2014.

slide-55
SLIDE 55

Making mission-critical software safe …

13

  • Risk-based coding rules
  • Six compliance levels.
  • Level 3: “We require that the flight software as a

whole, and each module within it, had to reach a minimal assertion density of 2%.”

Gerard J. Holzmann. Mars code, 2014.

slide-56
SLIDE 56

Making mission-critical software safe …

13

  • Risk-based coding rules
  • Six compliance levels.
  • Level 3: “We require that the flight software as a

whole, and each module within it, had to reach a minimal assertion density of 2%.”

  • Tool-based code review
  • Peer review great at discovering design flaws.
  • But tools are better at discover coding flaws.

Gerard J. Holzmann. Mars code, 2014.

slide-57
SLIDE 57

Making mission-critical software safe …

13

  • Risk-based coding rules
  • Six compliance levels.
  • Level 3: “We require that the flight software as a

whole, and each module within it, had to reach a minimal assertion density of 2%.”

  • Tool-based code review
  • Peer review great at discovering design flaws.
  • But tools are better at discover coding flaws.
  • Formal methods
  • Used for critical software and hardware components.
  • Provides high assurance but requires expertise, time.

Gerard J. Holzmann. Mars code, 2014.

slide-58
SLIDE 58

Summary

14

www.joelonsoftware.com/ articles/fog0000000043.html

The Joel Test for 403: 1. Do you use source control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do you do hallway usability testing?