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

Previous2017 SoCal Code CampNext2017 MathWorks Advisory Board

Last updated