Things that blew my mind
Tags: devops, testing, continuousdeployment, ci
Published: 2022-02-11 22:31:49

---
title: Things that blew my mind
published: true
date: 2021-12-31 00:00:00 UTC
tags: devops,testing,continuousdeployment,continuousintegration
canonical_url: https://jhall.io/archive/2021/12/31/things-that-blew-my-mind/
---

In 1995 I took a C programming course at my local university. I dialed into the university’s 28.8k modem pool, and typed my programs into their Solaris machines using [pico](https://en.wikipedia.org/wiki/Pico_%28text_editor%29).

My best friend at the time suggested I could install Linux—a _FREE_ Unix-like operating system—on my own machine, and save the hassle (and cost) of dialing long-distance to do my home work.

![](https://jhall.io/images/mind-blown1_hu604bb1bd4a4d87395695719d39b3bd81_83580_400x0_resize_q85_box.jpg)

In 2006, I started a new job doing Perl coding. I had heard of the idea of unit tests, and thought it was a neat idea, but who has the time?

Then I attended a conference where someone suggested writing tests _before_ they wrote code.

![](https://jhall.io/images/mind-blown2_hu3d7cde864dbca68283382e9b4081dcda_81840_400x0_resize_q85_box.jpg)

In 2010, I was the lead developer for a software project that would release once every couple of weeks. The release process took a minimum of two to three hours, and involved a lot of manual labor.

Then I heard that there were companies that were releasing [_multiple times per day_](https://www.youtube.com/watch?v=LdOe18KhtT4).

![](https://jhall.io/images/mind-blown3_hu28620b684600b9e23d6e46f21861fd27_92909_400x0_resize_q85_box.jpg)

One of the reasons it was so time consuming to release new code was that we had to do a lot of manual conflict resolution and regression testing before we were confident that each feature was ready for customer exposure.

Then someone introduced me to the concept of [trunk-based development](https://jhall.io/archive/2021/03/10/a-case-for-trunk-based-development/), and the idea that code on the `trunk` branch should _always be releasable_.

![](https://jhall.io/images/mind-blown4_huf955a97428938882e060e9a20d4c086d_85547_400x0_resize_q85_box.jpg)

Last week while discussing testing strategies, and shifting left, someone said that their organization practices [Test in Production (TIP)](https://www.optimizely.com/optimization-glossary/testing-in-production/). That is, they actually push code into production to do their tests. If it breaks something, they’re prepared for a quick roll back.

![](https://jhall.io/images/mind-blown5_hu21d23dd2d72f92b9e5d88c6a75e0eb09_70378_400x0_resize_q85_box.jpg)

Okay. That last one didn’t really blow my mind, as I’ve been advocating something like that for years. But I did see it blow someone else’s mind, with a violent reaction:

> Developers testing in Production?! They should concentrate on unit testing. Keep their noses out of PROD.

I can completetly identify with the sentiment this person felt, precisely because it’s exactly how _I_ felt with most of the other examples I’ve described.

The novel, game-changing ideas that change my career always feel like utter **BLASPHEMY** the first time I hear them.

* * *
_If you enjoyed this message, [subscribe](https://jhall.io/daily) to <u>The Daily Commit</u> to get future messages to your inbox._