Technical excellence - practices matter

Technical Excellence – Practices Matter
Global Scrum Gathering – Austin, TX

Bio
2
• Email: Leland.Newsom@emerson.com
• Twitter: @LelandNewsom
• LinkedIn: https://www.linkedin.com/in/lelandnewsom/
• Slideshare: https://www.slideshare.net/LelandNewsom
• Past roles include:
• Developer
• Manager
• Managing Director
• Technical Director
• Scrum Master
• Agile Coach
Leland Newsom
@LelandNewsom

Agenda
3
Dr. Semmelweis
How long XP & TDD has been around
Why technical practices matter
Technical practices
Results of using technical practices
How to get started
@LelandNewsom

How many people in the room are:
• Scrum Masters
• Development Team
• Product Owners
• Management
• DevOps
• Other
Quick Poll
4
@LelandNewsom

Dr. Ignaz Semmelweis
5
• 1846 Hungarian Dr. Ignaz Semmelweis ran a
maternity clinic at the General Hospital in Vienna
• At the start of when physicians were expected to
have scientific training and no longer thought
illness as an imbalance caused by evil spirts
• Considered scientific inquiry part of his mission
as a physician.
• Autopsies were more common and doctors got
more interested in collecting data.
• Studied 2 maternity wards in the hospital. One
was staffed by all doctors and medical students
and the other was staffed by midwives. He
counted the number of deaths on each ward.
• He discovered that in the clinic staffed by doctors
and medical students, women died nearly 5x
more than the clinic staffed by midwives.
@LelandNewsom

Mortality Rates
6
@LelandNewsom

What’s different
7
@LelandNewsom
• In midwives clinic, women gave birth on their sides.
– Semmelweis had women at the other clinic try it and results were “no effect”
• Noticed when someone died of childbed fever a priest would walk past the other
women’s beds and ring a bell. Semmelweis had the priest change their route and
ditch the bell. “It had no effect”
• One of his colleagues died unexpectantly
– Had pricked his finger while doing an autopsy on someone who had died of childbed fever
– Semmelweis studied and realized the colleague died from the same thing as the women he
had autopsied
– He hypothesized that there were cadaverous particles on the hands of doctors who performed
autopsies and those particles were being passed to the women who then developed the
disease and died
• If his hypothesis was correct, getting rid of those cadaverous particles should cut down on
the death rate from childbed fever.

Experiment with a New Practice
8
@LelandNewsom
Ignaz Semmelweis washing his hands in chlorinated lime water before operating.
https://www.npr.org/sections/health-shots/2015/01/12/375663920/the-doctor-who-championed-hand-washing-and-saved-women-s-lives

Mortality Rates after Washing Hands
9
@LelandNewsom

• Why were the other doctors upset?
– Made it look like the dr. were the ones giving childbed fever to women
– Doctors are gentlemen, how dare you say their hands are not clean
– Other doctors mocked him for it
• Eventually the other doctors gave up the chlorine hand-washing
and Semmelweis lost his job
• He kept trying to convince doctors in other parts of Europe to
wash with chlorine but no one would listen to him. This angered
him and he lashed out against his critics denouncing them as
irresponsible murderers or ignoramuses.
• Eventually Semmelweis was admitted to a mental asylum where
he was beat by the guards shortly after being admitted and died
in 1865 of a blood borne disease similar to what he was trying to
stop
– He was so rejected by the medical community at the time of his death
that he was neither honored nor recognized for his contributions
Upset Doctors
10
@LelandNewsom

• Louis Pasteur connected the germ
theory of disease with Semmelweis'
data and was more successful at
disseminating Semmelweis'
information.
20 Years Later
11
@LelandNewsom

How long has XP & TDD been
around?
12

• Many in the industry still don’t use the
practices introduced by XP in 1999
How Does Semmelweis’ Story Relate to Agile?
13
@LelandNewsom

• Kent Beck says he rediscovered TDD after reading
it in an ancient book about programming.
– It said you take the input tape, manually type in the output
tape you expect, then program until the actual output tape
matches the expected output.
• NASA is said to have used a test-first approach on
Project Mercury in the 1960’s
• Report of the NATO Software Engineering
Conference (1968)
• The Humble Programmer, by Edsger Dijkstra (1972)
• Out of the Crisis, by W. Edwards Deming 1982
How Old is Test Driven Development?
14
@LelandNewsom

December 1968 at the Stanford Research Institute, the modern computer was born.
https://www.nag.co.za/2018/12/10/the-mother-of-all-demos-is-50-years-old-today/
Software Engineering 1968
15
1. A software system can best be designed if
the testing is interlaced with the designing
instead of being used after the design.
2. A simulation which matches the
requirements contains the control which
organizes the design of the system.
3. Through successive repetitions of this
process of interlaced testing and design the
model ultimately becomes the software
system itself.
SOFTWARE ENGINEERING
Report on a conference sponsored by the
NATO SCIENCE COMMITTEE
Garmisch, Germany, 7th to 11th October 1968
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
@LelandNewsom

“…program testing can be a very effective
way to show the presence of bugs but it is
hopelessly inadequate for showing their
absence.”
“…one should not first make the program
and then prove its correctness, because
then the requirement of providing the proof
would only increase the poor programmer’s
burden. On the contrary: the programmer
should let correctness proof and program
grow hand in hand”
Edsger Dijkstra
Communications of the ACM, October 1972,
The Humble Programmer
Edsger Dijkstra - 1972
16
Xerox Alto – March 1, 1973
https://en.wikipedia.org/wiki/Xerox_Alto@LelandNewsom
https://cacm.acm.org/magazines/1972/10/11993-the-humble-programmer/pdf

Out of the Crisis, 1982
17
IBM Personal Computer 5150 – Sept 1981
http://oldcomputers.net/ibm5150.html
@LelandNewsom

Why Technical Practices Matter
18

13th Annual State of Agile - Reasons for Adopting Agile
19
@LelandNewsom https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

13th Annual State of Agile Report – Engineering Practices
20
@LelandNewsom

The Invisible Threat
21
@LelandNewsom
http://craftedsw.blogspot.com/2010/09/bad-code-invisible-threat.html

Technical Debt
22
@LelandNewsom

Deliver Value Incrementally
23
@LelandNewsom

Escaped Defects without Technical Excellence
24
@LelandNewsom

We’ll fix it later
https://www.flickr.com/photos/9266144@N02/1074851879
25
@LelandNewsom

Long Term Viability Requires Discipline
26
“Just put it anywhere” only works for a short time!@LelandNewsom

Scrum and Technical Practices
•“People have told me that they see Scrum as the management
approach to agile development and XP as the engineering
practices that make it effective, both bonded together by
complimentary practices and goals.”
– Ken Schwaber, co-creator of Scrum
•You don't see high performing Scrum teams without XP
engineering practices.
– From Jeff Sutherland, co-creator of Scrum
27
@LelandNewsom

Flaccid Scrum
• Martin Fowler, 2009 - https://martinfowler.com/bliki/FlaccidScrum.html
– They want to use an agile process, and pick Scrum
– They adopt Scrum practices, and maybe even the principles
– After a while progress is slow because the code base is a mess
• What happened?
– They didn’t pay enough attention to the internal quality of the software. Productivity
was dragged down because it became much harder to add new features and they’ve
taken on additional Technical Debt.
• Five Years Later… Martin Fowler, 2014
– My advice still stands - ensure you take technical practices seriously when introducing
Scrum (or any agile approach).
28
@LelandNewsom

Scrum Needs DevOps
29
@LelandNewsom

Organizational Agility
Organizational Agility is
Constrained by Technical Agility
30
https://less.works/less/technical-excellence/index.html
@LelandNewsom

We Can Do Lots to Build Quality In
32
@LelandNewsom

What is Test Driven Development?
• "Test-driven development" refers to a
style of programming in which three
activities are tightly interwoven: coding,
testing (in the form of writing unit tests)
and design (in the form of refactoring).
• It is succinctly described as the Red –
Green – Refactor loop.
– Red – Write a failing unit test. Validate that
the test fails
– Green – Write “just enough” code to make the
test pass. Validate the test passes.
– Refactor – clean up the code and test for
simplicity, readability, and maintainability. Re-
run test to ensure all works as expected.
33
@LelandNewsom

Uncle Bob’s 3 Laws of Test Driven Development
1.You aren’t allowed to write any
production code until you have first
written a failing unit test.
2.You aren’t allowed to write more of
a unit test than is sufficient to fail.
And not compiling is failing.
3.You aren’t allowed to write more
production code than is sufficient
to pass the currently failing test.
34
https://sites.google.com/site/unclebobconsultingllc/
@LelandNewsom

Add/Edit Test
Run the Test
Make a small
code change
Run the Test
Refactor
(if needed)
Pass
Fail
Fail
Pass
Test-First Development Flow
How It Works:
1. Add/Edit a Test
• Helps to clarify work items because you have to figure out
what inputs you need and what outputs you expect
2. Run the test and see it fail
• Ensures test harness is working correctly
• Ensures that test does not mistakenly pass
3. Write some code
• Only write what is needed to pass the test
• No additional functionality should be included because it will
be untested
4. Run the automated test
• If test fails repeat step 3
• If tests pass, can be confident code meets all tested
requirements
5. Refactor code
• Cleanup the code
• Rerun tests to ensure cleanup did not break anything
6. Repeat
35
@LelandNewsom

Reduces Debugging Time
36
@LelandNewsom

Debugging with Print Statement
37
“Whenever you are
tempted to type something
into a print statement or a
debugger expression, write
it as a test instead”
– Martin Fowler
@LelandNewsom

Why not commit each time the code is
in good shape?
• Frequent commits help minimize the
amount of code lost if you need to
revert to last good version
• Commit history coincides with test that
was just added
• Depending on how complex the
refactoring step is, you may want to
commit after last green and before
refactor
Red-Green-Refactor-Commit
38
https://ardalis.com/rgrc-is-the-new-red-green-refactor-for-test-first-development
@LelandNewsom

test && commit || revert
39
@LelandNewsom
https://www.slideshare.net/540deg/katayuno-tcr-test-commit-revert?qid=06f662b4-8e76-4f93-a277-652e8a9acca2&
Image from @bberrycarmen

Tests Remove the Fear of Legacy Code
41
Stop fearing legacy code:
• Learn what the code does
– Use characterization tests
– Do scratch refactoring
• Make sure it keeps doing it
– Write tests to prove it still works the way it
previously did
• Iterative improvement via Refactoring
– Small changes at a time
– Isolate small sections of code
@LelandNewsom

When we refactor, we should have tests.
To put tests in place, we often have to refactor..
The Refactoring Dilemma
42
@LelandNewsom

Working Effectively with Legacy Code
43
❖Parametrize Constructor
❖Extract Interface
❖Characterization Tests
❖Techniques for breaking dependencies
❖Scratch Refactoring
❖And a lot more techniques for improving
existing code bases.
@LelandNewsom

What is Pair Programming
44
• 2 People
– Driver - Collaborates with the navigator
and controls the mouse and keyboard
– Navigator – Collaborates with the driver
and actively reviews code in real-time
– Switch roles frequently (at least every 15
min) and ensure each person has at least
2x in each role
• 1 Computer
@LelandNewsom

Why Pair Program
45
• Shared Code Ownership
• Continuous Code Reviews
• High Productivity
• Lower Waste
• Low distraction
• Increased Focus
• Higher Quality
• Knowledge Transfer
@LelandNewsom

Pair Programming and Productivity
46
“When people say that
Pair Programming reduces
productivity, I answer, that
would be true if the most
time consuming part of
programming was typing”
– Martin Fowler
@LelandNewsom

Ping-Pong Pairing
47
@LelandNewsom

Strong Style Pairing
48
@LelandNewsom

Continuous Integration
49
“Continuous Integration is a software development practice
where members of a team integrate their work frequently,
usually each person integrates at least daily - leading to
multiple integrations per day. Each integration is verified by
an automated build (including test) to detect integration
errors as quickly as possible. Many teams find that this
approach leads to significantly reduced integration
problems and allows a team to develop cohesive software
more rapidly.”
– Martin Fowler
@LelandNewsom

Continuous Integration Simplified
50
Developer pair makes a
change to a source file
Run unit tests
locally – all pass Developer pair push the
changes to source control
The build server
retrieves the changes
and builds
Automated tests
and other quality
checks run
Pair is notified
of build and test
results
@LelandNewsom

51
Run unit tests
locally – all pass Developer pair push the
The build server
and builds
Automated tests
and other quality
checks run
Pair is notified
of build and test
results
@LelandNewsom

52
Run unit tests
locally – all pass
The build server
and builds
Automated tests
and other quality
checks run
Pair is notified
of build and test
results
@LelandNewsom
Developer pair push the

53
Run unit tests
The build server
and builds
Automated tests
and other quality
checks run
Pair is notified
of build and test
results
@LelandNewsom

54
Run unit tests
The build server
and builds
Automated tests
and other quality
checks run
Pair is notified
of build and test
results
@LelandNewsom

55
Run unit tests
The build server
and builds
Automated tests
and other quality
checks run
Pair is notified
of build and test
results
@LelandNewsom

Continuous Integration at Scale
56
Integrate
Push to Source
Code Repository
Auto Build
AutoAuto
Unit Tests
Code Quality
Check
Adapted from: https://www.pluralsight.com/guides/devops/everything-you-need-to-know-about-continuous-testing
@LelandNewsom

Google Developer Scale
30,000 + Developers
45,000 commits per workday
1 billion files
2 billion lines of code
800,000 builds per day
150 million test cases run daily
57
@LelandNewsom
“Automated tests transform fear into boredom”
- Eran Messeri, Google
Source: Gene Kim - @RealGeneKim
https://www.slideshare.net/realgenekim/2019-top-lessons-learned-since-the-
phoenix-project-was-released

Behavior Driven Development (BDD)
“BDD is a second-generation, outside-in, pull-based,
multiple-stakeholder, multiple-scale, high-automation, agile
methodology. It describes a cycle of interactions with well-
defined outputs, resulting in the delivery of working, tested
software that matters.”
–Dan North
58
@LelandNewsom

BDD Development Process
59
https://medium.flatstack.com/applying-behavior-driven-development-to-ruby-on-rails-web-applications-
using-rspec-cucumber-and-2c893c3ab7eb
@LelandNewsom

The Three Amigos
60
PO Developer Tester
Happy
Path Exceptions,
Border
Cases
Technical
Feasibility
@LelandNewsom

Before BDD
61
As a store owner, I want to attract new
customers by offering them a 10%
discount on their first order so that we
can grow our online sales.
public void CalcDiscount(Order order){
if (order.customer.IsNew)
order.FinalAmount =
Math.Round(order.Total * 9/10);
}
Register as “bart_bookworm”
Go to “catalog/search”
Enter “ISBN 123456789”
Click “Search”
Click “Add to Cart”
Click “View Cart”
Verify “subtotal is 33.75”
@LelandNewsom

Common Language?
Product Owner
62
Development QA
@LelandNewsom

Common Language
63
As a store owner, I want to attract new customers by offering them a
10% discount on their first order so that we can grow our online sales.
Scenario: New customer gets 10% off order
Given a new customer creates a new account
And the user searches “ISBN 978-0131177055”
And book costs $37.50
When the user selects “Add to Cart”
Then the book should be in the shopping cart
And the shopping cart sub-total should be $33.75@LelandNewsom

BDD Example
64
https://en.wikipedia.org/wiki/Behavior-driven_development
@LelandNewsom

Results of using Technical Practices
65

Applying XP Practices
66
The average cost to address a
defect rises exponentially the
longer it takes you to find it.
@LelandNewsom

Return on Investment – Agile vs. Traditional Methods
• Agile method’s ROI is 3
to 17 times greater
than traditional
methods.
• Two major factors
– High benefits
• Productivity
• Schedule
• Customer Satisfaction
– Low costs
• Improved quality
• Maintenance
67
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods.
@LelandNewsom

Programmer with Good Habits
69
@LelandNewsom

Excellence is a Habit
70
@LelandNewsom
https://www.captechconsulting.com/blogs/blog-series-did-you-pack-the-
12-agile-principles-on-your-agile-journey-pt-9-technical-excellence

Getting Started
• Practice
– Code Kata
– Code Dojos
– Code Clinics
• Training
– Uncle Bob’s Clean Coders videos
– Pluralsight
– Bring in trainers
– Books / Blogs / Youtube
• Start somewhere
– New code comes with tests
– Bugs needs test that prove they found the bug first
then fix it
– 80/20 rule of code changes
• 80% of the changes come from 20% of the code
– Find your 20% of the code that changes and
refactor & write tests there
71
@LelandNewsom

Learn More
• Practice code katas
– https://cyber-dojo.org/
– http://kata-log.rocks/index.html
– https://github.com/emilybache
• There are a lot of blogs and articles on the web. A few suggestions to start:
– https://martinfowler.com/
– https://blog.cleancoder.com/
– https://cleancoders.com/videos
• Also a lot of books on the subject
– Here are a few classics
73
@LelandNewsom

What Questions Do You have?
74
@LelandNewsom

Technical excellence - practices matter

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Technical excellence - practices matter

Similar to Technical excellence - practices matter (20)

More from Leland Newsom CSP-SM, SPC5, SDP

More from Leland Newsom CSP-SM, SPC5, SDP (8)

Recently uploaded

Recently uploaded (20)

Technical excellence - practices matter