DevOps #10: Deploy Independently with Workspaces and Workloads

How Can We Deploy Independently Without Chaos? Continuous and independent deployment sounds great from the team’s perspective. Nothing blocks the flow of value. They can ship each feature when it completes, and fix any bugs with an immediate rollback. The team can interact quickly and directly with customers through A/B tests and previews, and they can do all of this free of the company bureaucracy around release management, timing, and overhead. But from the organization’s perspective, continuous and independent deployment […]

DevOps #9: Ease Integration with Hexagonal Architecture

How do I Know I’m Using My Dependencies Correctly? Our goal is to simplify integrations between my component and my dependencies. Using techniques from the last two newsletters, we can isolate my component from unwanted complexity in a dependency, and then verify that the dependency continues to work as I expect. However, one glaring hole remains: how do I ensure that my code uses the dependency correctly? We’ve Already Solved Almost Everything You may recall that we have encapsulated each […]

DevOps #8: Find Integration Bugs without Integration Tests

How Do I Keep This Working? A team that has been following this year’s Devops Series and performing each technique would find themselves able to: Plan features without dependencies, Edit code independently, Build and verify independently, Isolate changes, and Isolate its integration complexity from its main collaborator. For that team, this is great progress and things seem pretty good for a while. Work is fast, deployment is practical, and integration bugs are lower than they’ve ever been. But then integration […]

DevOps #7: Isolate Integration Complexity

How Will We Debug the Monolith? If your teams are following our approach to escape the monolith that Deep Roots has provided in this year’s newsletters, you can probably see a big problem looming. Your teams are gaining independence at the cost of increasing integration complexity. Who is going to manage that complexity as every team flees the monolith? How? Let’s look at our example organization to understand the complexity and its solution. Nearly 2000 components (125 teams * 10+ […]

DevOps #6: Compile Independently With a Forward-compatible Component

I’m Waiting For the Build…Again! Continuing our case study from the last two articles, let’s focus on one of the 130 teams who were trying to break free of the monolith. At this point this team had created their component. Actually, there were several components, but each was just a namespace in the monolith. Only one team changed each component, but every change still forced them to recompile the monolith. And every team had to recompile the monolith and every […]

DevOps #5: Gather A Scattered Component

We also support our readers through the Code by Refactoring Slack channel. Please join us there to discuss any part of the technique along your way to gathering your own scattered component. My Code is Everywhere! Let’s continue with the last newsletter’s example of an organization with more than 100 teams editing a single codebase. The codebase was well-structured. It had to be in order to support that much change. It had a well-designed, cleanly-implemented 4-tier architecture. The key innovations […]

DevOps #4: Extract Components to Edit Independently

Other People Keep Messing with My Code! I was working with a company that had about 100 teams in the same product. Each had a different purpose, so each changed different code. However, it wasn’t as clean as that makes it sound. Each team found itself making contributions across a quarter of the product. Each change impacted the work of a few other teams. Each method or class was shared among 2–4 teams — but it was a different 2–4 […]

Sadly this Legacy Code Works. How Do I Get Permission to Fix It?

I got a good legacy code question today in the Code by Refactoring Slack channel. We have a code module called the state machine which is poorly written and has no tests. We all (we the engineers) agree that we should rewrite the state machine from scratch. However, the current implementation ‘works’, and we are not adding states or other stuff to that module. Here’s the questions: a) Do we need to add tests (unit & integration tests) at all? If yes, […]

Technical Debt vs Technical Waste

Executive Summary In trying to improve productivity and reduce waste there are 3 important concepts. These often get confused, which makes it difficult to align and fix the problem. The key concepts are: Technical Debt — a way your system has not yet incorporated new information. Technical Waste — technical friction that does one of 3 things: puts existing business at risk, or causes delays and increases costs to respond to new information when it appears (aka, manage technical debt), […]

Naming as a Process (Article 1)

We all know naming is a pain in the ass and you can’t trust the names in your code. But it doesn’t have to be that way. Many people try to come up with a great name all at once. This is hard and rarely works well. The problem is that naming is design. Here are the things you are typically trying to do all at once while naming: Deciding the things the code should do Deciding which things go […]