sarah allen

FRI, NOV 9 @ 11:00AM

@ultrasaurus

Crafting Software Products

How do you craft a software product that people want to use? This talk will explore how agile design is different from agile development, yet both disciplines need to work together to create a product. What are the methodologies that help us figure out what code to write? We don't want to create a stack of paper specs to define the product far in advance, but neither do we want to dive into coding before we've figured out who will use our product and what problem we're solving. What do we need to do before we start writing code? How do we use test-first techniques outside of the code to validate that we are building the right product, while remaining productive in the face of change?

aaron bedra

SAT, NOV 10 @ 12:00PM

@abedra

Pontificating Quantification: Verifying Correctness in Software

In 1969, Tony Hoare published a paper that would change computer science forever. He reflected on the ideas of consequence in program execution and created a set of formal definitions for proving correctness. This is a far cry from how most software is verified today: through automated unit testing in the style of X-Unit. In this talk, Aaron will brave the forgotten paths of software verification beyond the realm of unit tests. He will look at some of Hoare's original concepts and how others have built on them, gain a deeper understanding of type theory and the limitations of language-integrated proof systems, and finally examine the restrictions that can be imposed on language expressiveness to make verification more tractable.

gary bernhardt

SAT, NOV 10 @ 9:00AM

@garybernhardt

Boundaries

Some people test in isolation, mocking everything except the class under test. We'll start with that idea, quickly examine the drawbacks, and ask how we might fix them without losing the benefits. This will send us on a trip through behavior vs. data, mutation vs. immutability, interface vs. data dependencies, how data shape affords parallelism, and what a system optimizing each of these for natural isolation might look like.

michael feathers

FRI, NOV 9 @ 4:00PM

@mfeathers

Testing Revisited

We write tests. We use to them to probe design, maintain the behavior of our code when we change it, and demonstrate that it is working. All of these things are valuable. Why then, do we sometimes feel that our tests own us? That we are spiraling down a path of over-testing and maintenance headaches?

In this session, Michael Feathers will talk about how we can reframe our relationship with automated testing, maintaining the bulk of their utility without unreasonable costs. Doing so takes courage, but no more courage than we have applied to other aspects of development.

cory foy

FRI, NOV 9 @ 9:00AM

@cory_foy

When Code Cries: Listening to What Your Code is Saying

Christopher Alexander defines building as alive or dead based on how well they resolve the forces of the people who use them. Likewise, the software we write can be alive or dead. In this talk, Cory Foy will explain how you can listen to the things your code is saying to you as it cries out to be great, and mold it into something that teems with life.

sarah gray

SAT, NOV 10 @ 11:00AM

@fablednet

Visualizing Enumerable: Own Abstract Concepts Through Physicalization

One of the things that stops beginner programmers from owning their knowledge is a difficulty visualizing what is happening when a line of code runs. We Rubyists are happy using our terse, expressive language—but without a mental model, beginners can be lost when it comes to "seeing" what's happening when the code executes. In this session, Sarah will go through some of her visual representations of Ruby's Enumerable Module in order to illustrate pathways through the code for some commonly used—and commonly misunderstood—methods. This talk will demonstrate alternate learning approaches for people who are visual or physical learners. Good for non-beginners, too, as anyone who has ever tried to explain #inject will testify.

leon gersing

SAT, NOV 10 @ 4:00PM

@rubybuddha

Keep Software Weird

How much code coverage does it take it ship a minimal viable product? How many Scrum Certifications does it take to make your team agile? How many languages learned make a journeyman a master? Currently, in software, there is an expressed desire to be taken seriously as craftspeople. To this end, we've introduced process, metrics and quantifiable boundaries as goal posts to hold up to those who may not understand what is involved in shipping quality software. As this practice becomes normal, developers are faced with an ever-expanding landscape of techniques, practices and pressure from thought leaders to take extra course work or certifications to validate the assertion that you are, in fact, a software developer. While some may see this as a necessary evolution of our field, I see it as a albatross round the neck of the creative developer looking to explore the depths of what is possible. While the safety of a well worn path may provide solace to the uninitiated, I find dogmatic implementation oppressive and exclusionary to those interested in exploring alternative approaches to solving problems with technology. Join me in an exploration of what I believe makes us unique as a subculture in this business world; examples of how we came to be by challenging the established idioms of the past in order to move forward into something exciting and new. To be our best we must be willing to dive into the unknown, to loose the binds of convention and explore the vast expanse of the unfamiliar. We must dare to be wrong, to be new, to be foolish, to be amazing and keep software weird.

brian marick

SAT, NOV 10 @ 2:00PM

@marick

Logic Programming and Test Data Generation

Primum: Logic programming computes values for variables based on relationships between known facts. In the main, introductions to it are either based on logic puzzles (cannibals and boats!) with an at best unclear relationship to the problems we write programs to solve, or on laboriously reimplementing things (arithmetic!) that we can already do perfectly well, thank you very much.

Secundum: Generating complex test data is a hard problem, in part because constraints (relationships) amongst bits of the data have to be obeyed. The sadly common result is fragile tests that know too much about the details of their data.

Ergo: I will explain logic programming by showing how it can be used to generate test data from minimal descriptions of what's needed.

robert martin

FRI, NOV 9 @ 2:00PM

@unclebobmartin

The Reasonable Expectations of Your CTO

Welcome. I am your new CTO. I know that in the past we've had some quality problems, some productivity problems, and some morale problems. I know that you've sometimes felt overworked and under-appreciated. I know there have been issues of trust between you and the rest of the business. But that's the past. I have a different expectation of what you are capable of.

I believe you are all world class programmers, engineers, and craftsmen. From now on I'm going to expect you to behave that way. Indeed, I have a list of very specific expectations that I want to go over with you now. These expectations are reasonable, rationale, achievable, and will define us as the world-class, highly professional, deeply competent team that I know we can be.

jen myers

FRI, NOV 9 @ 3:00PM

@antiheroine

Developers Can't Understand Design (And Other Completely Mistaken Design Myths)

Designers are designers and developers are developers and never the twain shall meet, right? Except—not really. There are some imaginary lines drawn around the two disciplines of design and development, but the truth is they are closely intertwined, and it can be very useful for software creators to be able to understand the value and process of design. This presentation will correct some commonly-held misconceptions about design and focus on how software development companies can integrate designers into their workflows in order to create clearer, cleaner and more usable applications.

adewale oshineye

FRI, NOV 9 @ 12:00PM

@ade_oshineye

What Happens When Software Craftsmanship Meets User Experience?

Developer Experience (also known as DX or DevExp) involves applying the tools and techniques of User Experience professionals to developer-facing artefacts. In this talk I'll walk you through the basic principles of DX and show why failure to apply them is hurting your work. I'll describe some DX patterns we've gathered and share some of the painful lessons we've learned as we've evolved Google's APIs. Finally I'll argue that craftsmanship has to manifest itself in every interface, API, and tool we expose to our fellow software developers if we as an industry are to move forward.

susan potter

SAT, NOV 10 @ 3:00PM

@SusanPotter

Functional Algebra: Monoids Applied

In functional programming, words from Category Theory are thrown around, but how useful are they really?

This session looks at applications of monoids specifically and how using their algebraic properties offers a solid foundation of reasoning in many types of business domains and reduces developer error as computational context complexity increases.

This will provide a tiny peak at Category Theory's practical uses in software development and modeling. Code examples will be in Haskell and Scala, but monoids could be constructed in almost any language by software craftsmen and women utilizing higher orders of reasoning to their code.

chad pytel

FRI, NOV 9 @ 10:00AM

@cpytel

Apprentice.io

http://Apprentice.io is a new apprentice program which trains developers and designers in a three month apprenticeship. This talk will give an overview of how the program works and review the important lessons learned.

justin searls

SAT, NOV 10 @ 10:00AM

@searls

To Mock or Not to Mock

Some say "mocks suck," because they reduce a test's realism and with it the confidence that the code being tested actually works. Others use mocks to demarcate the outer boundary of an application, guarding the test from expensive or external dependencies (e.g. by faking a database or network resource). Still others see mocks as a "setup of last resort", using them only to mitigate the pain of hard-to-test code. Finally, some developers mock out every collaborator in every test, and their rationale is probably the least understood of them all!

This talk will serve as an opinionated (if broad-stroke) survey of the different ways people use test doubles (be they mocks, fakes, stubs, or spies). Our goal will be to establish a more sophisticated means of communicating on the topic. We'll discuss the pros & cons of the different approaches toward mocking, the smells of test double abuse, and the lessons I took away from writing my own test double library.