2017 SCNA
Software Craftsmanship and the Safety Critical World
Philip Markgraf
Synopsis Software Craftsmanship and the Safety Critical World Take a look into the world of regulated software development for safety critical applications. Hear what life is like working under international regulations for software processes and how craftsmanship-focused practices can be fit into those hierarchies. Learn about the impacts of schedule pressures when lives are actually at stake, and how failures lead to heavier regulatory burdens. And, hopefully, you can pick up a few techniques for your own developments!
Notes
Phil speaks from the medical devices perspective
IEC 62304
Extreme Programming in the Medical Device World
Extreme Programming Explained, Kent Beck
In-device testing is crazy slow
Testing physical processes that take minutes to measure
Single sub-system test takes more than two hours
Automated formal verification test takes nearly a month
Automated testing
Simulated patient
Simulate user interactions
Test-modes to simulate hardware failures
Formal hazard analysis
Many requirements developed as hazard mitigations
System hazard analysis is clinically focused
Evaluate modes of failure your products have experienced
Investigate industry history of failures to identify modes that you have not experienced
Devise means to mitigate risks
*Design to avoid the issue
Continuous built-in test
Directed review
Look at AAMI TIR32, Medical device software risk management
Continuous checksum test
Continuous check that the space between stacks are never written to
Me: IEC 62304 doesn't seem to have requirements based testing?
Architecture & design documents:
Kept as thin as possible
Explain the "why" that you could not infer easily from code
Focus on aiding our "future selves" who will have to maintain the software
Techniques for Quality
Design to eliminate mode
Immutable data can't cause concurrency bugs
Multiply by fraction can't divide by zero
Improve defect discover
Use chaos engineering techniques
Hello Chaos Monkey
How do you inject stress on the application
Use generative testing to explore input cases example-based test miss
Quality First Approach
"The only way to go fast is to go well"
Bug fixing higher priority than feature development
Fixing bugs first means that the bugs you know about can't hide the bugs you don't know about
Avoids the intuitive "the problem you just saw is the one we already know about"... when it is actually something else
Make your test reports clear
When his team failed to fix the issues first, feature development soon slowed as well
Fewer features, but complete. Avoid the "many features, all half-done" syndrome
System tests drive unit tests, unit tests drive code
QA should find no bugs!
More important to have quality and to have the next feature
Quality Team
Build a quality culture
Grow the team you have
Choose the right new people
Lead by example
Choose quality first
Repeat the reasoning behind choosing quality
Training
Teach team values
Expose team to new ideas
Mentoring
Distribute responsibility for growing culture
Not only from experienced members to junior members, but recent grads should be mentoring the veterans things they might have forgotten
Dealing with Business & Schedule Pressures
Understand repercussions of bad code
Progress slows over time
Issues hidden from discovery and leads to discovery by customers
In medical devices, recalls cost WAY more than delayed releases
Quantify cost of outages / failures
Examine costs in customer confidence
Building trust with Business
Delivery on time
Business needs to have an overall plan, to know what can be accomplished, when and at what cost
Proof of progress
Business needs to see progress in a running system, proven to work by passing repeatable tests
Not a Silver Bullet
Regulation does not create bug free code
You can't "regulate in" quality any more than you can "test in" quality
Software failures beget more regulation
Work with the Regulations
Use process to lift quality
Steps can fit your workflow
You have to meet them, you may as well see benefits!
Mob Programming: A Whole Team Approach
Woody Zuill
Synopsis Mob Programming is a development approach where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders.
This is an evolutionary step beyond pair programming, and accentuates the face-to-face communication, team alignment, collaboration, and self-organizing team concepts of Agile and Extreme Programming. Mob Programming can be a highly effective approach. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.
Notes
Opening Quote: "The value of another's experience is to give us hope, not to tell us how or whether to proceed." -Peter Block
Mob Programming
Definition
All the brilliant minds working
On the same thing
At the same time
In the same space
On the same computer
All the needed skills and knowledge gathered together
Completely different, all together
Mob programming can be done remotely...a virtual mob
Advantages of Mob Programming
Short feedback loops
Focus
Reduced software defects
Knowledge transfer
Training is built-in
Woody suggests that teams he's spoken to has wanted to work this way, not because it was mandated by management
Roles
Driver/Navigator
Originated with pair programming
Navigating at the level of detail for the driver to do the work
Examples:
Get on the 405 North is enough for most drivers
Need more detailed instructions to direct a driver to an unknown place
Strong pairing
"For an idea to go from someone's head into the computer it must go through someone else's hands" -Llewellyn Falco
The driver will learn as they go
The driver is just translating the concepts to the screen
Be aware of cognitive noise
Application
Driver rotates every 7-10 minutes
How mob programming came about
Team needed to learn to interact well with each other
Studied together
The team decided to use the coding dojo method
"Turn up the good"
Computational Thinking
Sarah Aslanifar
Synopsis Does a five-year old know something about computer science that you don't? Maybe, if you think you need a computer to think like a programmer! Inspired by Seymour Papert's classic "Mindstorms" and "Turtle Math", Sarah's been experimenting with teaching her five and three year old sons some techniques to think like a programmer. In this talk, we'll see the results.
Notes
"The story of computation is the story of humanity" -Grady Brooch
Facts about children
Predict events when something happens
Mom grabbing the keys probably means they'll likely be leaving soon
Can understand cause/effect
Understand relative size
Rudimentary sense of numbers
Born with all the neurons in life
Only a quarter of the connections (synapses) one develops throughout life
Mindstorms
Suggests introducing mathematics as a language to children
Use every day tasks as opportunities of computational thinking
Teaching physical games (i.e. Set game) may make it easier to make the jump to abstract mathematical concepts of sets
Guidelines
Be patient
Be persistent
Do not have high expectations
Jeffrey Karpicke (Purdue) - Studies learning
Repeated spaced technique is the best
Repeat three times, but space the repeats
Cubetto 10% discount at www.primotoys.com: SCNA2017
System Architecture as Network Data
Bobby Norton
@bobbynorton
bobby@testedminds.com
Synopsis Architecture is both structure and process. The elements of a system, their impact and dependencies on one another, and their relationship to the environment comprise the structure. The principles guiding the system's evolution of function and behavior over time create a design process.
All systems have architectures. Not all of them are well-documented or understood. Diagrams can help, but these are often manually curated and therefore doomed.
The dependency structure of all systems can be modeled by networks...graphs that represent something real. When architecture is network data collected automatically, we can apply rigorous practices from the systems engineering and network science community to reason about our designs in a principled way.
How can we optimally organize our code and our teams? What parts of the system are the most important to test? When should we build a monolith or use microservices?
In this talk, we'll explore these and other findings from applying this architectural approach to open-source projects and to a quickly growing organization.
Notes
"Controlling complexity is the essence of computer programming." Brian Kernighan, Software Tools, 1976
ThoughtWorks
Claim: Automated network analytics enable modularity and agility
Posits that systems engineering and Agile work well together
"The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected." [Rechtin, 2000]
Bobby seems to be talking about a graph of the software
Me: This structure can be visualized in Understand C
Systems architecture as a network of dependencies
Me: This idea was expressed in the MBE summit
Except in MBE, the good tools give rules for how the edges may be connected to the vertices
Coupling and cohesion can be understood in network terms:
Loosely coupled -> few dependencies between modules
highly cohesive -> dependencies within modules
Cytoscape
Free tool to visualize networks
Jupyter notebooks
Combine documentation and a repple
Similar to MATLAB's live scripts
Bobby's tool (lein topology plugin to Leinigraph) give quantitative analysis of the modularity of the analyzed codebase
The novelty here is receiving an algorithmic recommendation about how to improve the organization of the code
Mocks aren't stubs!
0-deductible insurance is expensive
You pay the premiums when you refactor the tests every time you refactor the code
100% interface coverage > 100% test coverage
How big is the system?
Number of verticies and edges
Lines of code in each vertex (class /package / namespace)
Modularity score (a function of a number of modules and dependencies between modules)
How well is the system tested?
% test coverage of module boundaries
How well is the system documented/
Documentation of module boundaries
Who is building what parts of the system?
Examples can be found at:
www.github.com/testedminds/
Is the best software written alone?
Elizabeth Engelman
@ebethme
Synopsis Is the best software written alone? For a lot of us, the answer to this question is a quick "no". But pair programming may not be the silver bullet either. Let's take a closer look as to why collaboration can lead to better software while also exploring techniques for more productive partnerships. In this talk we'll explore personality types and learning styles in hopes of better understanding our fellow software crafters to be able to work together more effectively, while considering diversity and inclusion amongst our teams.
Notes
Me: Having detailed notes for a presentation can be bad because you may reply on reading the notes as opposed to speaking to the audience.
Pair programming may sometimes be destructive if the partners are mean-spirited
Teamwork is hard, even the team already has a good relationship
Pair programming is a dialog between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better." [Extreme Programming]
Advantages of pair programming
increase creativity
Knowledge transfer
Opportunity for mentorship
Catching mistakes/less errors
Continuous review
Reduced cognitive load
Pair mismatches
Personality type mismatch
Myers-Briggs Type Indicator
Extroversion/Introversion
Sensing/Intuition (How to injest new information)
Thinking/Feeling (How to use information in decision making)
Judging/Perceiving
Me: Strengths finder
Learning style mismatch
VARK
Visual
Maps
Charts
Graphs
Diagrams
Arrows
Aural/Auditory
Discussions
Understand things by speaking first
May restate facts, or ask obvious questions
Background noise may be distracting
Read/Write
Lists
Dictionaries
Quotes
Words, words, words
Kinesthetic
Reeall-life, concrete examples
Demonstrations
Trial and error
Hands-on learning
Mixed modality
Indentifying with more than one learning style
2 Types of multimodality
People who can swtich from mode to mode
People who want to satisfy all of their preferred modes
Experience/expertise mismatch
Me: I think this is a good way for the more experienced person to mentor and teach novice people, and for novice people to relate new ideas from academia
Elizabeth addresses this
The expert must have the patience and capability to be an effective teacher to work with a novice
Expert Characteristics
Distinct approach for their work
Recover more gracefully from istakes
Have an underlying confidence in their ability
Store and retrieve information differently and more efficiently than no-experts
Elizabeth suggests that expert/novice pairings are good, but the durations should be watched so that both parties can take breaks to manage the inherent frustrations involved
Be comfortable knowing there are people you may not be a good fit as pair programming partner, even if you are good friends
Pair programming is a conversation
Asking for solo time for unstructured play with the code
Opening debuggers or consoles to intuit the information differently
The ABCs of Learning
Quantum Computing
Federico Spedalieri
Synopsis Quantum computing holds the promise of vastly more efficient information processing devices that could revolutionize a wide range of fields. First generation quantum computing devices have been commercially available for a few years, and others are being developed both by industry and government agencies. But how are these machines programmed? In this talk I will give a brief introduction to quantum computing and discuss some of the challenges one encounters when programming these devices.
Notes
Federico cancelled due to illness
Teal Organization in Development (or is it Production)
Amanda Laucher
@pandamonial
Synopsis The Teal paradigm refers to the next stage in the evolution of human consciousness. When applied to organizations, this paradigm views the organization as an independent force with its own purpose, and not merely as a vehicle for achieving management's objectives. Teal organizations are characterized by self-organization and self-management where the product is not pre-determined by management, but the organization itself. The organization is the product. Non-violent communication, ego as the enemy, and openness to new and scary ideas are several tenets of Teal in production. Fast feedback loops, full transparency, radical candor are tools that help us along the path.
Although Mined Minds has not fully achieved its Teal goals, in this talk I'll share the path we are on as we strive towards Teal. You'll hear about our fits and starts, the experiments that have worked, those that haven't been great, and a lot of other things we have learned so far along the way.
Notes
How to become a better software craftsperson: a colorful guide
Reasons a project is great:
Solving fantastic & hard problems
Great team
Didn't feel like work
Truly agile, things move fast
Reinventing Organizations, Frederic Laloux
Holacracy
Created by Zappos
What makes work suck
Politics
Bureaucracy and infighting
Color Categories
Red: Command & Control
Amber: Rules & Processes
Orange: Competition & Achievement, Meritocracy
An orange organization would describe themselves as a well-oiled machine
Green: Values Based, Culture Driven, Team Empowerment
Teal: Evolutionary Purpose, Self Management, Thinking about the Whole
Experiment Driven, Fail Often & Fast
Would say they aren't competing with others doing the same thing, but that they are working with the others for a common purpose
Jobs, Roles & Responsibilities
Doesn't matter what you're hired for, you bring to the company what makes you feel whole
Me: This seems very much like millenials, but how does this work in reality?
Antifragile Software, Russ Miles
Success is not the focus
Me: "Journey before destination"
Incremental progress
Release attachment to outcomes to really analyze the data
Striving for whole
Hypothetically an individual who stack ranks really low in the organization but who is a multiplier on any team their on, means you keep the individual despite the person individually is very poor
Work life balance?
Take care of person hobbies, responsibilies, self if that will help you be the best at work
Advice Process
Unless someone doesn't have a really good reason you shouldn't do the thing you want to do, you can go ahead and do it
Emergency Situations
Bring issues to the entire team
Conflict Resolution
First, one-on-one
Second, bring in a mediator
Third, bring in a panel
Self staffing projects
Make sure you don't negatively impact the team you're already supporting
Make sure a team ends up not staffed
Share with the organization what you want to do
Focus on Individual's Callings
Help people reach the goals they have for themselves, and not just what the oranization wants
Salary
Salaries are open
Understand the company's entire budget
Set personal salary knowing the above two
Trust Me, I'm a Leader
The whole system depends on trust
Leadership has to buy in to this
Ownership
Owner is willing to pay for the mistakes of individual contributors
Openness takes time & causes anxiety
Takes a very specific type of person willing to "see behind the curtain"
Today, your company is very unlikely to turn teal
Advice:
Go back to your office, and change anything you don't like
Experiment to prove out the change is needed
Trust junior engineers
Allow evolutionary design
Start talking about your personal goals regularly and figure out as a team how you can reach them
Books:
An Everyone Culture
Ego is the Enemy, Ryan Holiday
Nonviolent Communication, Marshall B Rosenberg
Last updated