Thursday, February 04, 2021 in Escape the Monolith
Our Unit Test Suite Hurts! TDD, CI, and DevOps assume that unit tests have the following traits:
Domain relevant: Test one thing the user cares about and could describe. One Way to Fail: Can only fail for one reason, which is its assertion. Independent: Execute only the code they verify. You don’t need to update the test if anything else changes. Cover Functionality: The set of tests as a whole cover all behaviors of the system.Thursday, March 19, 2020 in Surviving Disruptions
As consumer confidence has plummeted, wooing new customers with exciting new features is less likely. However, engendering loyalty among your customers as they look through their subscriptions and decide what to cut seems a very wise plan.
Not only do your customers not really care about snazzy new features, but it’s the kind of work that does not flourish within the remote environment. Well done feature development requires communication across many different roles that is good, frequent, and fast.Thursday, March 04, 2021 in Escape the Monolith
Our Code is Hopelessly Entangled With the Monolith! We really want our code to be a set of services. That unlocks CD and DevOps. However, our code is currently a long ways away from being Service Oriented so we will get to services incrementally.
Our first target is Continuous Integration (CI). We think of CI as a system to rapidly find mistakes so that we can correct them. However, the power of CI comes from an unexpected source — team independence.Friday, March 27, 2020 in Surviving Disruptions
It’s safe to say that the world is in a state of disruption that organizations are navigating all at the same time. The book Zone to Win describes how to organize in times of disruption. Moore’s premise is that during stable times every company plays in three of the four zones. However, when disruption happens, a fourth zone comes into play … the transformation zone.
Companies die when they transition poorly from stability to disruption.Tuesday, April 06, 2021 in Escape the Monolith
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 teams each time.Wednesday, April 08, 2020 in Surviving Disruptions
Imposed change on a global scale shifts how the world works. For example, the industrial revolution eventually replaced cottage industries with at-scale manufacturing. Similarly, the rise of the Internet shifted the meaning of expertise from what-you-know to what-you-can-find-and-apply. And now we are watching another global shift, from tolerating remote work to embracing it as a value. We are seeing the first glimmers of a new reality. Last week we wrote about mindshifts that are necessary to prepare your technical teams for the ways of working required by COVID-19.Tuesday, May 04, 2021 in Escape the Monolith
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.Wednesday, March 25, 2020 in Surviving Disruptions
Our world is in a state of emergency. Today’s uncertainty and ambiguity means we can’t assume everybody can be back in the office shortly.
And truthfully, this is an opportunity. In the office, informal technical communications covered for many weaknesses. Technical skills that were good enough in the office won’t work well in remote work, where informal communication is limited. Excellent technical skills, however, allow developers to communicate informally through the code.Thursday, July 08, 2021 in Escape the Monolith
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.Thursday, April 02, 2020 in Surviving Disruptions
In the United States we are a month into the quarantine, give or take a little depending on your geographic location. Dr. Fauci, Director of National Institute of Allergy and Infectious Diseases, informs us that the infection rates will not truly curb until a vaccine is created. While J&J and other companies are working to deliver a vaccine, we know this is not a quick fix. Regardless of how many safety protocols they are ignoring to speed delivery.Thursday, August 12, 2021 in Escape the Monolith
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.Tuesday, March 17, 2020 in Surviving Disruptions
Are you prepared to lose 120 hours a week for each development team?
As a manager, I would assume that sending development teams home for remote work, as we must right now, would still achieve productivity. After all, so many developers work remotely very easily and they seem to do well in quiet alone spaces. Of all the quarantine disruptions, this one seems minor, right?
Mmmmmm…not so minor.
Developers Need to Share Tacit Knowledge Technical development frequently requires tacit knowledge that is shared in close verbal quarters.Thursday, September 02, 2021 in Escape the Monolith
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.Monday, October 18, 2021 in Escape the Monolith
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 of our dependencies behind a Port.Thursday, November 18, 2021 in Escape the Monolith
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 promises sheer chaos.
Tuesday, January 05, 2021 in Articles
I Can’t Automate This! Many years back I inherited a 30-year-old legacy code base. We were to clean up the C++ and make it work on modern hardware. However, the first step was to get it to even compile.
Before us, building the product required 3 specialized build engineers, each with individual knowledge and unusual machine configurations. Each would remap the source, compile, get a partial success and set of failures, then pass it on to one of the other two.Friday, October 30, 2020 in Articles
Don’t Make Me Touch Ordering! The PM thought the feature was simple. And it should have been. Unfortunately, it requires making a tiny change to payment processing. And payment processing is part of the Order system…which is one monster class.
More than half of our code depends on Order to do something. Each part of that code depends on the Order for a different set of responsibilities. Although there are patterns, the Order class’s sheer size and number of responsibilities make these patterns hard to see.Monday, August 31, 2020 in Articles
My Service Interaction Tests are Slow and Fragile! Any legacy system needs to connect with other systems. However, coding and verifying changes in your legacy system requires the following things.
Simulate remote faults and verify your response. Verify that what you send to the remote system will cause it to do what you want it to do. Know when a release, rollback, or failover of the other system will change a behavior that you depend on.Wednesday, August 26, 2020 in Articles
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?Thursday, July 30, 2020 in Articles
My product is written in the wrong language! Legacy systems tend to be old, and thus written in languages and frameworks that were available at the time they started. It’s no one’s fault, but the code is in the wrong language. This causes:
Slow development. Difficult testing - my tech predates the TDD movement. Reinvention - libraries for new techniques are written in new languages. Difficult hiring - my tech predates most developers.Thursday, June 25, 2020 in Articles
I hate changing the database! Legacy databases present two challenges:
Bad schema that is hard to change. Too much logic in the database. Both delay stories and generate bugs. Both waste your time and each will require thousands of person-hours to fix. We need to find a way to pay that cost incrementally; preferably divided among all the developers on the project.
First let’s divide the problem in half by ignoring the logic for now.Thursday, May 28, 2020 in Articles
All I want to do is edit the freaking document! Unfortunately, so does everything. CDocument is central to what we do. Users think of documents, and so does the UI. Every piece of code reads the CDocument class…unless it modifies CDocument.
And now I need to unit test my code. Also, I want to ship my team’s code independently of the other team. But every single feature touches CDocument. Many of them change CDocument - or one of the 6 wrappers we have created around CDocument over the years to reduce changes to CDocument.Wednesday, May 27, 2020 in Articles
What do you hear with the terms “scaling learning?”
The most common reaction focuses on the logistics. This results in many less-than-adequate web-based training programs.
The idea of scaling learning also suggests that a LOT OF PEOPLE need to consume the learning. Developers may not like legacy code, much like instructional designers do not like wide audience delivery. Put together a nice little niche piece of learning? Fun! Make learning work for 100% consumption over a large audience?Thursday, April 30, 2020 in Articles
I changed a piece of code and 75 tests broke… It was a simple feature. I just added a GDPR approval checkbox when creating a new account. And suddenly half our tests broke. Tests for reporting, tests for core features, all kinds of tests for all kinds of things. Because every one of them needed to create an account.
So I added a default to the test mocks. I updated lots of expecteds.Wednesday, February 19, 2020 in DevOps Concepts
You are responsible product manager. You carefully hone your multiple ideas. You split test (A-B test) to refine and pick the best ones to invest. You build out the winner. You make your big release … and it flopped.
What happened!? You put in all the effort to make sure this won’t happen, and yet it did.
Getting the right data. What you didn’t know was that several of your tests had a small cosmetic bug on one treatment.Monday, February 03, 2020 in DevOps Concepts
Releases had been delayed, slow, and buggy. You fought that for awhile and then adopted the magic of DevOps, which promised automated pipelines to get fast feedback. This also was supposed to give the developers the ability to easily fix production problems when they happened.
After all of that, you find yourself rushing to make quick fixes while the system keeps telling you that it’s still broken. This churn wastes development time, promises 2am work on live-site issues, and inures people to the red light.Friday, December 06, 2019 in Articles
You schedule sprints that do nothing but clean up the previous sprint. You are told that features you feel are critical to the product “simply can’t happen”. You watch feature after feature ship late and then get long bug reports.
However, you have not been idle. You’ve contracted process and technical consultants. They gave you answers and you got the green light to implement them. Things did improve, but your bottom line issue of buggy and late deliveries continue to happen.Wednesday, November 13, 2019 in Articles
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), orMonday, October 28, 2019 in Articles
Our background and experiences inform our instincts … and your instincts tell you that productivity is low because technical waste is in the way. How can teams possibly be effective working through the maze of quality issues they face?
You have instituted process changes to help them reduce WIP. You have established the roles recommended to make communication clearer and faster. You have embraced the recommendations you’ve heard at conferences or from consultants.Thursday, October 17, 2019 in Naming as a Process
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 together Deciding which abstractions best represent those clusters Picking a name that clarifies intent Picking a name that distinguishes from all the other similar intents Describing the side effects of the code Keeping your name under 15 characters This is why naming is hard.Thursday, September 26, 2019 in Articles
Is technical waste really a threat?
Sure it costs a lot of money, but that is small compared to the revenue from a successful software product. You attained business success by maximizing the odds of revenue. You could afford some technical debt along the way.
But now that debt has become waste. Technical waste is not just costing money. It is costing options. Want to take the product to the cloud?