“[Teams] are not stupid, just ignorant. They’ve been trained to deliver complete features. That’s the problem. It’s one of the hardest habits to break.”
It’s such a treat to have Bryan on, his second time on the show with us. Hey, it’s Denis—what I adore about Bryan is his candour and ability to challenge the status quo and invite new ideas into modern-day engineering practices.
As an avid agilist and continuous delivery enthusiast he spearheads the minimumcd.org initiative while also being a head technologist at 🦄 Defense Unicorns, bringing continuous delivery practices to environments such as submarines and secure military platforms.
Thank you Bryan!
What problem is Continuous Delivery solving?
There’s a few:
I have a stable way to fix production at 3am in the morning while I’m tired and stressed
It forces us to drive all waste out of the process. This makes it far less expensive to try new ideas
It drives down the cost of delivery which encourages more experimentation
If you solve these 9 challenges of CD then your organisation will deliver better against your business goals and your culture will improve. You can’t have a toxic bureaucratic terrible culture to work in.
What problem does Trunk-Based Development address?
It’s getting you into a releasable state faster.
—How?
Because it’s removing friction so you can get a smaller batch of change.
Batch size is so important: if I have a smaller change set it’s easier to code review on, it’s harder to break and I can get faster feedback on that small change.
If I have to get through several hoops to get there it’s going to naturally disincentivize me to doing small batches of work. If small batches become too expensive, it incentivises larger batches.
Adrian: If you do CI, if you do CD and trunk-based development it solves the cultural issues, you work as a team. Doing synchronous reviews—
Bryan: It takes so much teamwork to get things done [without CD].
Pull system vs. Assigning Tickets
It’s psychological. If we’re pulling work then I’m highly invested in making sure that everything that we are signing up to do I’m aware what it is and how we’ll get it done.
If we do sprint planning where I get 4 tickets assigned I don’t care about them.
Adrian: Assigning tasks gives you no guarantees of completion. It creates another backlog that requires management and supervision when things go wrong. When leaders see no progress it incentivises more deadlines and control.
Smaller Batches
—Developers need to understand how to break up work into smaller batches.
You actually have to take testing seriously. When moving fast in small batches you can’t just throw code over the wall and hope it works. My focus became less: “How do I deliver this feature faster?” and instead it has become “How do I test this better?”
You should test everything around you for value.
—So why do so many teams work in large batches?
They’re not stupid, just ignorant. They’ve been trained to deliver complete features. That’s the problem. It’s one of the hardest habits to break.
How to plan software projects?
The mental model most people have of software development is wrong because they ask for these long-term plans. And they think it’s manufacturing. There is manufacturing in software develoment. It happens after I push code, it goes to the robots.
—What hard problem does having a plan solve in a non-software project?
It’s capacity planning. It’s making sure we’re delivering the right amount of things at the right time.
—Why is that important?
I’m not an expert in manufacturing. I know that if you’re building an assembly line that there’s stations on the assembly line and you need to make sure that you have a consistent flow and you’re not backing up batches waiting on stations.
I think of the robots and how we architect the robots [in CD] the same way.
—So far everything you said is sound and if I just add the software to it it sounds completely disfunctional.
The problem with software is they think it’s manufacturing instead of inventing new things.
What did the Gantt chart look like for inventing the first lightbulb?
Unless we’re refactoring well-tested code we have a lot of uncertainty to what we do.
It’s inventing new capabilities all of the time. We’re building assembly lines for drills where every single drill is different than made before. It’s all bespoke. You can’t put hard expectations on success and timelines when you’re inventing new capabilities.
Productivity Metrics
Denis: When I coach teams they often plan too far into the future. If their planning accuracy right now is 10% for a 3-month period, then let’s not talk about 2 weeks. Let’s talk about tomorrow. Can we predict what will happen tomorrow to the degree that we are 95% that this gets DONE by tomorrow and it’s VALUABLE.
[Bryan once more from here on]
There’s some hard benchmarks I use for are we going to be an effective team or not:
If we can integrate code every single day—minimum daily— we have a good chance in being an effective team
None of our stories requires story point. Every story takes two days or less. Preferably less to get to a predictable level of certainty
Test-driven Development
Full disclosure, I don’t always use TDD. I’m always disappointed in myself when I have to clean up a mess that I caused and I didn’t.
TDD forces you to think outside-in
It makes you create declarative tests instead of imperative tests
It acts as a forcing function on the modularity of your system
Holistic testing without being end-to-end. If you have code written with tests in the TDD/BDD way it impacts design. It’s not about design, but it impacts it. It’s not about testing but it impacts testing.
The thing that helped me the most with low-level design was reading Domain-driven design.
Opportunities to solve HARD PROBLEMS as a software engineer