Seth Goings

Software Engineering Manager @ Microsoft (Azure Container Service)

Read this first

Leading a DevOps Movement

Nearly every conference I attend (DevOpsDays included) makes me feel like a kid in a candy store. I get a sugar rush being around all these sweet new tools, techniques, and methodologies - things that promise to solve a headache or two of mine. Actually - Willy Wonka hits the nail on the head:

If you want to view paradise, simply look around and view it.

Anything you want to, do it;

You want to change the world? There’s nothing to it!

Candy!

With all these new ideas and tools the conference has brought to my attention, I’ll very likely go searching for problems that this new tool will solve with ease. Someone said they needed their build fixed!? Ooh! I’ll fix it up right quick with this new hammer of mine!

But with all this excitement I quickly find myself in trouble. Some examples I’ve encountered:

Continue reading →


Running A Benevolent Puppet Regime

In March I presented the talk: “Running a Benevolent Puppet Regime” at Denver’s first ever PuppetCamp Denver! Held within the Code Talent building in Denver’s RiNo neighborhood:

The presentation content is available on SlideShare, but since the slides were designed to be an aid to my verbal story telling and not the primary method of communication, I figured a port to a blog post would also be helpful.

The whole presentation is also available in video form, if you want to sit through my yammering for 45 minutes.

Road To Production

If you don’t know much about me - I’m interested in building elegant systems in life and in my career. I don’t just care about how a system looks from the outside but also how every part of the

Continue reading →


DevTools Through the Ages at ReadyTalk (2014)

Today Doug Borg and I presented ReadyTalk Engineering’s maturation in continuous delivery over the course of the previous year and where we’re headed in the year ahead. Feel free to tweet at Doug or myself if you’d like to know more about what we’re up to!

Continue reading →


Principles of Continuous Delivery

I recently watched a presentation from Dave Farley outlining the “Why” of Continuous Delivery. In the presentation, Dave delivered a slide that outlines the guiding principles of the continuous delivery movement:

  1. Create a repeatable, reliable process for releasing software.
  2. Automate almost everything.
  3. Keep everything under version control.
  4. If it hurts, do it more often - bring the pain forward.
  5. Build quality in.
  6. Done means released.
  7. Everybody is responsible for the release process.
  8. Improve continuously.

Keep these in your back pocket while you’re in the trenches, improving tools, making process decisions, and getting lost in the weeds. They should be your guiding light as an executive, product owner, manager, engineer, or tester in the world of software development.

Continue reading →


ReadyTalk’s CI Team

A while back… ok way back in 2013, Doug Borg and I recorded a presentation describing what the ReadyTalk CI Team does. If you’re interested in what we as a team focus on to improve builds, deployments, quality, and #DevOps… have a watch. It’s a riveting 30 minute presentation we’ve used internally that has held up surprisingly well to the test of time.

Continue reading →


ReadyTalk Pipeline DSL

If you’ve used Jenkins for any amount of time you might like its configurability and extensiblity but also understand that this flexibility poses serious drawbacks to his continued use. I feel as though Jenkins suffers mostly from a lack of a few fundamental software tooling patterns on a job configuration basis:

  • convention over configuration (having an opinion)
  • single source of truth (opinion is easily shareable)
  • desired state resolution (stated opinions are practiced)
  • single-command initialization (opinions are accessible)

I’ve always enjoyed the model of TravisCI‘s in-repository yaml file build job configuration, which provides all these aspects… but wasn’t available for Jenkins jobs. I also appreciated the actual implementation of a Jenkins deployment pipeline using Gradle that Benjamin Muschko and Peter Niederwieser from Gradleware presented last year, but thought it could be a

Continue reading →


If Only “They” Knew

Do you ever wonder why so much software in the world seems to be overly complex, incomprehensible, or just plain messy?

And then, say, you contact “the owner” to address the situation and they see nothing wrong?

Doesn’t that infuriate you?

If only “they” knew how terrible their code was!

You might be interested in hearing about the Dunning-Kruger Effect.

In the late nineties, David Dunning and Justin Kruger, psychology professors at Cornell University decided to test several hypotheses around the behavior of incompetent people by acquiring a pool of unsuspecting undergraduates under the guise of free pizza.

Behind me you’ll see a few simple graphs of the data as I talk through the details and findings.

The test procedure was pretty simple and went something like this:

  • before the test, each student would guess how well they’d do on the test (we’ll call this the “perceived test

Continue reading →


Feature Branching

I recently made some waves on Twitter (and other circles) regarding my dislike of “Feature Branching.”

The bigger the apparent reason to branch, the more you shouldn’t branch
@jezhumble

Feature branching is a poor man’s modular architecture… you’re coupling
yourself to source control and manual merging
@DanielBodart

The quote is more powerful when not limited by character count:

“Feature branching is a poor man’s modular architecture, instead of building systems with the ability to easily swap in and out features at runtime/deploy time, you’re coupling yourself to the source control providing this mechanism through manual merging” (Daniel Bodart)
Since that time, I’ve been thinking about why I have so much pent-up anger toward feature branching:

I think my main beef with feature branching is that branches for a feature too easily turn into a long-lived, isolated, work of art that

Continue reading →


Kevin Behr Reading List

I recently asked Kevin Behr @kevinbehr | kevinbehr.com for some ideas on good reading material regarding his expertise (which is quite vast). He responded with a 3 part tweet, and so this post is to document the recommendations in a more organized fashion, as I’d love to work through this stuff, but it’s going to take a while

  • Theory of Constraints (TOC)
  • @goldrattbooks
  • Eli Goldratt
  • @skholt
  • William Dettmer
  • Bob Sproull
  • Cynefin
  • @snowded
  • @cyetain
  • Non Violent Communication (NVC)
  • Art of Action
  • Surprising Purpose of Anger
  • Scientific Method in Brief
  • At Home In The Universe
  • @flowchainsensei
  • @drunkcod

Continue reading →