Agile Alliance Technical Conference 2017

Abstract:
We no longer live in a world where we build our applications from scratch. We build amazing creations using the blocks provided by libraries, frameworks and components. We trust widely and openly. We share and collaborate.
We design architectures that combine simple single purpose entities into massive complex coupled systems.
Then we try to secure them. What could possibly go wrong?
In this talk we will explore how our approaches to development, architecture and trust change the security of our applications and environments. We will discuss the challenges of securing these systems and some of the practical steps we can take to bring simple security to complex systems.

Learning Outcomes:

• * Learn how software development has changed to help us go faster and build amazing things
• * Understand how this has changed how we view risk and vulnerability
• * Gain hands on pragmatic things to do and think about in your own teams

Abstract:
So you’ve deployed your app, launched your site, and gone live in prod: so far, so good. But what happens when people actually use it, when you find out where your IaaS rate-limits you, and when you can’t just throw (virtual) hardware at your software problems?
Let's explore the practical realities in that vast, uncharted space between "waiting for the change control board is probably fine" and "we just implemented a novel time series data store in our spare time." If you’re coming to this talk, you may be well past the former, while the latter remains strictly aspirational. What matters these days in operations when you're dockering all the Dockers, going serverless with lambda functions, or scaling beyond what you’ve seen before? Getting the abstractions right is a non-trivial task.
I'll chat about the new stuff worth running in production, dispel myths (NoOps is not a thing; serverless still has servers), and answer questions (spoiler alert: the answer is "it depends"). If you've put in a non-zero number of hours on the pager and still can joke about it, you know that a Someone Else's Problem field lasts just long enough for it to become our problem. Let's talk solutions.

Learning Outcomes:

• Attendees will leave better prepared to deal with the new realities of an operational role.

Abstract:
This talk is for people who are having difficulty creating and maintaining application architectures. While test-driven development, automated testing and continuous integration are great practices to facilitate local design and making changes without risk, the architecture within which these changes take place will have a large impact on the effort required.
The Agile community is recognizing the need to address the challenges of Architecture at Scale. While many people recognize the importance of patterns, they tend to focus on patterns as a set of solutions. This often leads people to try to develop by combining patterns. This is actually the anti-thesis of the true intention of design patterns. In reality, patterns are a way of thinking – the patterns themselves are a result of this thinking. Attendees to this session will learn how to scale up their application of design patterns to larger systems, resulting in the longer lived, more robust designs we all strive for.
This seminar has three parts to it:

• A quick introduction to Design Patterns Thinking
• Simplifying complex models with commonality-variability analysis
• Using design patterns thinking and a model of issues in a problem domain to create and maintain an application architecture

Learning Outcomes:

• Understanding that patterns are more than mere "solutions to recurring problems in a context"
• Understanding the thought process behind what makes patterns good solutions
• Learn how to identify the issues in your problem domain you are trying to solve
• Reduce the complexity of these forces by making a distinction between the issue and potential implementations
• Learn how to ceate a simplified model of the issues to be managed in the application – in particular those issues that tend to vary
• While design patterns live at the code level, these concepts live from code to high level design. The trick is to create a way of applying these technique at much greater scales. Fortunately, this technique already exists – commonality-variability analysis – introduced by James Coplien and extended with the analysis matrix by Al Shalloway. Using CVA, one can takek these concepts up to any scale.

Red - Green - (refactor)

We all know that refactoring is suppose to be the step that let’s us tease apart the logic of our code. ‘Fake it till you make it’ allows for us to evolve an emergent solution to complex problems. Yet this is usually glossed over when showing Test Driven Development.

But not in this session. Here we are going to focus completely on Fake it till you make it. Taking complex katas and reducing them to

1 Red - 1 Green - 40 Refactors.

Abstract:
Have you had a hard time figuring out where to start with Test-Driven Development. What if ZOMBIES could help you build code that does exactly what you think it is supposed to do? What if ZOMBIES helped you build a test harness that can keep your code clean and behaving as expected for a long and useful life?ZOMBIES can help!
I'm not talking about a legion of undead or virus stricken. ZOMBIES is an acronym that helps you, the engineer, decide where to start, what test to write next and make sure that, to the best of your ability, you do not forget critical tests and production code behaviors. We'll go through the though process and steps with a detailed code example.

Learning Outcomes:

• ZOMBIES' foundation is in the Zero-One-Many (ZOM) programming pattern
• To provide additional guidance behind ZOM, the programmer needs to constantly pay attention to
• Behaviors
• Interfaces
• Exceptional situations
• while defining Simple test Scenarios

Abstract:
When I look back at every time I have not written a unit test first. It was either because I didn’t really know how to do it effectively, or how to do it at all.
Of course, this doesn’t mean it can’t be done, just that I hadn’t learned how to… yet.
This session is about how I’ve learned to test many things I used to think were impossible. Usually in a just a few lines of code.
Want to test that a gui looks right? No problem.
That the Html and CSS render correctly. Piece of cake.
Is the noise reduction function making the audio sound better? I can do that.
That database query from the ORM is working? Sure. Even if the database is down. Yep!
This is going to be a compare and contrast type session. We will look at lot’s of examples of standard unit tests vs the same test using an ApprovalTesting framework like: TextTests, PealFish, Depicted (dpxdt) or ApprovalTests.

Learning Outcomes:

• The 4 benefits of testing
• Increasing Feedback
• How to create custom asserts
• How to test many 'untestable' things

Abstract:
Sure, it works on your machine. But how confident are you that your Linux servers provide the same runtime environment as your Mac laptop? And when there's a security hole somewhere in your app stack, how quickly and safely can you upgrade to fix it? How much happier would you be if you could generate identical software configurations for your dev and prod boxen, no matter what OS they run?
Stop crossing your fingers that brew-ing here and apt-get-ing there will produce matching results. You deserve DevOps happiness! Learn how to pronounce "pkgsrc" -- and how a practical, proven cross-platform package manager can save you from the kind of surprises that ruin your week.

What to bring

• A laptop,
• Running any Unixy OS (Windows even counts, if you're feeling adventurous),
• With a working C compiler,
• And a downloaded, unzipped pkgsrc-current tree

Learning Outcomes:

• How pkgsrc helps you...
• - Install the shiniest, newest Git
• - Package a famously gnarly Ruby gem from source
• - Package Vim with an embedded interpreter for Ruby, Python, Perl, or Lua
• - Update OpenSSL to address the latest vulnerability (can't wait to find out what it'll be this time)
• - Build your own custom set of ready-to-deploy binary packages
• - Package up your own application using its existing build process

Abstract:
The production of software is a complex, collaborative process that stretches our ability as human beings to cope with its demands.
Many people working in software development spend their careers without seeing what good really looks like.
Our history is littered with inefficient processes creating poor quality output, too late to capitalise on the expected business value. How have we got into this state? How do we get past it? What does good really look like?
Continuous Delivery changes the economics of software development for some of the biggest companies in the world, whatever the nature of their software development, find out how and why.

Learning Outcomes:

• Why and how does Continuous Delivery change the economics of software development? What does excellence in software development process look like? What are the fundamental principals that enable organizations around the world to benefit from these techniques?

Abstract:
*These five development practices are core to Extreme Programming (XP)—automating the build for continuously integrating software as it is written, collaborating with team members through pair programming, practicing agile design skills that enable testability, using test first development to drive design, and refactoring code to reduce technical debt. Together, these five technical practices are proving to be essential for sustained success with agile development. However, many teams haven’t been exposed to the benefits of these practices or understand how to use them effectively. David Bernstein explores these engineering practices and their use in reducing risk and building quality in at every level of the development process. He makes the business case for these practices by showing how they address the inherent risks and challenges of building software. David then examines how XP practices address the core issues of software development by helping us “build the right thing” and “build the thing right.”

Learning Outcomes:

• *Gain a deeper understanding of XP practices and why they are not what they seem
• Use continuous integration to reduce risk in building software
• Employ pair programming to propagate knowledge throughout the team
• Recognize five code qualities at the core of all good developer practices
• Adopt test driven development to rapidly build higher quality code
• See how refactoring is used to help you work faster by reducing technical debt

Abstract:
If there's one technical agile practice that everyone has a different opinion about, it's testing. The debate between the Chicago (no mocks) and London (mocking) schools of thought has been going on for more than a decade! Some claim that if you believe in POs and BAs writing acceptance tests with Gerkhin you're living in fairy land. Others that writing automated tests is a waste and that cheap QAs should catch all the bugs instead. And just to name a few influencers on opposites of the spectrum: @DHH thinks TDD is dead; while @KentBeck wishes there were more examples of what not to test!
We see a lot of value in TDD and BDD but are not blindly obsessed with these practices. We don’t question the value of having tests for your project, but we do question the value of testing absolutely everything. Over the years, we've discovered that deleting tests is just as important as writing them!
In this workshop, you will see real examples of tests we've seen (or written ourselves) that we don't believe add value to your test suite. You will also have a chance to discuss why you would delete, rewrite or rethink these tests

Learning Outcomes:

• You'll leave our session with an informed opinion on what not to test in your project and, who knows, maybe you’ll even start deleting some of your tests. What’s more, you'll better understand how to test what is essential.

Attachments:

• dontTest-AATC 2017.pdf
• WhatNotToTestWorkshopEnglish AATC2017 handout.pdf

Abstract:
Legacy code. It's those dirty brownfield applications that no one wants to work on. How do you make sure that your project never becomes one of those dreaded projects? And if you’ve inherited a dirtfield app, how do you turn it back around into a gorgeous greenfield?
The answer to both of these questions may surprise you: seeding your app with good communication artifacts. In this talk, Andrea Goulet, the CEO of Corgibytes, a shop that specializes in working on legacy code bases, will give you specific and immediately actionable ideas to ensure the legacy of your codebases stays as green as possible. You’ll learn how to:
● Avoid interruptions by effectively “seeding” artifacts throughout your work ● Use the ideas of inception layers to talk about your availability ● End the dreaded git blame game
● Create code that continues to provide value years after you write it.
If you’re ready to take your code legacy to the next level, this is one talk you won’t want to miss!

Learning Outcomes:

• *

Abstract:
Most of us have worked in situations where a large amount of effort is spent addressing defects, support calls and technical debt. I recently worked with one team where they estimated that only 20% of their time was devoted to new value work and 80% of that effort was spent working around the technical debt. In other words they are operating at less than 5% of their potential.
How does code get into such horrible shape? The pattern seems pervasive enough that an appeal to craftsmanship is insufficient. I believe that there are larger systemic forces at play.
In this talk, I will present technical debt, not as a problem but as a measure. It is a measure of the technical health of your organization. Large technical debt is analogous to high blood pressure. Addressing high blood pressure likely entails a lifestyle change involving diet, exercise and so on. Addressing the symptom of technical debt will similarly shed light on organizational changes such as hiring practices, optimizing for project delivery over sustainable product development and so on.

Learning Outcomes:

• deeper understanding of the root causes of technical debt
• appreciation of the connections between value streams, organizational structure and technical health
• insights into improving technical health in your organization

Abstract:
Conceptualization and understanding are prerequisites for changing software. But they become harder to achieve as software becomes more complex and expands in scope. We have many tools for writing software, but few at all for reading and understanding it. What if there were tools that helped us conceptualize systems so that we could change them with greater confidence? What would they look like and how would we use them?
I will describe a new approach that helps developers rapidly build understanding of new software systems by generating an Idealized Commit Log: a simplified step-by-step deconstruction of a working software system. I will explain how the tool works by touching upon a diverse set of topics including type analysis, code coverage tools, AST transformations and a much-ignored topic of academic computer science pioneered nearly forty years ago called program slicing.

Learning Outcomes:

• A better understanding of the problem of software comprehensibility
• History and foundations of program slicing
• A new approach for understanding software

Abstract:
In a sprint to deliver features, software qualities or “non-functional requirements” such as security, performance or reliability can be slighted or sometimes even ignored. This hands-on workshop introduces you to several patterns and practices for weaving quality-related work into your project rhythms and techniques for keeping system quality requirements in mind, measurable, and tangible. You will also learn some options for how you can adapt these practices to fit your preferred way of working.

Learning Outcomes:

• Understand how quality-related activities can fit into your development process
• Understand the mechanics of writing agile quality scenarios and quality-related acceptance criteria
• How to define and use landing zones to incrementally specify key system qualities
• How to run an agile quality workshop
• Options for writing system quality scenarios
• Know the difference between read-do and do-confirm checklists and natural pause points for running a quality-related checklist