MAN VS TREE
A young man was walking down his street and saw his neighbor chopping down a tree in his yard. The young man stopped and watched for a while and noticed his neighbor getting very frustrated as he wasn’t making much progress; he kept hitting and hitting, but it seemed that his strikes weren’t making a dent in the tree.
The young man called out, “It looks like your axe isn’t very sharp anymore. Wouldn’t it help if you stopped to sharpen it?”
The neighbor replied, “I don’t have time to stop. I must keep chopping.”
The young man said, “But a sharper axe would make chopping go faster.”
The neighbor barked, “I already told you I don’t have time!” so the young man kept walking, leaving his neighbor in frustration.
There are a dozen or more versions of this story, but each one highlights the need to carve out time for renewal and refreshment. “Sharpen Your Saw” is one of the habits in Steven Covey’s 7 Habits of Highly Effective People. As an individual, to be productive, you should invest time in improving your physical and mental wellbeing so that you can best accomplish your tasks and serve others; you cannot be at your peak if you’re striking a tree with a dull axe. Software teams can’t operate to their full potential with a dull axe either.
Teams are often driven by goals and outcomes – and are often rewarded for those outcomes (like chopping down the tree). But we should seek opportunities to slow down for the short-term and invest in tools and processes so that teams can move faster in the long-term. Think: “How can my team chop down an entire forest?” Shifting the mentality from “short term win” to “long term investment” can be challenging, but the payoff will be worth it.
GAINING AWARENESS: SIGNS OF A DULL AXE
The first step to addressing any issue is to gain awareness of it; we can’t sharpen the axe if we don’t recognize that it has become dull in the first place. When it comes to developing software, sometimes awareness is gained when things don’t feel right:
- You try to fix a bug and others keep popping up (we call it “whack-a-mole”).
- You build a new feature on code that is brittle and you’re spending more time fixing old code than you are writing new code.
- You realize that you’re the only one who knows how-in-the-world a particular feature works. Or the same person on your team is consistently the only one working in a particular area of code.
- Someone from another team or group asks you to explain your code and your explanation leads to a diagram that looks suspiciously like spaghetti…
…these are the signs that your axe may be dull.
Like the neighbor in our story, we may resist taking the time to stop to sharpen our tools. Perhaps we don’t want to speak up, for fear of conflict. Maybe we are so focused on meeting the goals, that we prioritize doing it fast over doing it right. It feels counterintuitive to stop swinging the axe when you feel the pressure to deliver to your stakeholders and customers; but continuing to swing a dull axe not only reduces the effectiveness and morale of the team, but it can also be incredibly costly path to travel as well.
When you get to the place of “This doesn’t feel right” or “This is taking longer than it should because we live in The Land of Spaghetti Code”, it’s time to stop chopping. At Realtracs, we call this “stopping the line,” reflecting a principle from Lean Manufacturing where workers pull an Andon cord to alert there is an issue, and the production line stops until the issues are resolved. Team members are empowered to stop the line at any point during the process. The sooner the cord is pulled, the sooner action can be taken to address issues, reducing the amount of waste and churn in the process.
TAKING ACTION: SHARPENING YOUR AXE
Once the cord has been pulled, it’s time to assess the situation and act. Often, the issue is old code or brittle code and requires some degree of refactoring. Some benefits of refactoring are to simplify the code (i.e., is the same thing being done in multiple places and/or is it overengineered?) and to ensure everyone on the team understands how it works.
In many organizations, “refactoring” is seen as an elusive goal that will never be seen. But for us, we view refactoring as an investment, something we know that will pay dividends down the line. We know that taking the time to get it right now will allow us to build faster (and with higher confidence) in the future. During this time, the entire squad is focused on that body of work; no new work is pulled. The focus is on ensuring that a strong foundation is being set for future work.
Stopping the line also provides a great opportunity to invest in team members and team morale. In our experience, it brings everyone together to work through a singular problem, ensures knowledge is spread (and code is documented for future team members), and improves communication across the team. During this time, we strive to have open communication and dialogue with one another. If there is a strong subject matter expert on the team, we work to share knowledge across the entire squad. If one person is taking on too much, we work to help delegate and reassign other duties/tasks. Just as we want our code to be high-quality, we aim to have strong trust and psychological safety among the squads as well. This ensures that when issues arise in the future, team members feel confident and empowered to stop the line early in the process.
CELEBRATING THE ACCOMPLISHMENT: SEEING THE WORK PAY OFF
Slowing down and focusing on a refactor can feel like climbing a mountain…but experiencing the payoff and benefits of the investment is so rewarding. Recently, our entire team has been practicing sharpening our respective axes. As we expand into new markets, we know that the foundation of our product must remain strong. One such area is our search platform; searching is a mainstay of Realtracs and will continue to be relied upon as buyers and agents navigate the current housing market.
Over the past 12-18 months, we’ve been investing heavily in our search platform to best serve our agents and their clients. We have a legacy system that is over five years old and was not built with mobile usage in mind. As technology has evolved and demand has shifted to using mobile devices, we had to shift to meet that demand as well.
We began by creating a new search experience with a mobile-first approach that could be utilized on both mobile and desktop devices. In early 2021, a Realtracs mobile app was released! But over the next few months, as more features were added on top of the new search platform, performance issues and technical debt began piling up. Around this time, a team member who had a deep knowledge of the search domain was promoted and moved off the squad and new team members joined. Because deep domain knowledge was no longer directly on the squad, bug fixes took longer, and the squad found that they seemed to be solving the same problems over and over. The combination of team members leaving/joining the squad, a backlog of future feature requests, and an under-performing search platform prompted the team to stop chopping and start sharpening their axe.
One area of early investment was our “search criteria engine.” Prior to our refactor, searches were coupled with the existing user interface (UI). We knew that we did not want those items to be coupled and we knew that there was room for improvement in the quality of the code. But with this work also came a fair amount of risk: infrastructure already existed and was being used by our customers. We needed to ensure agents could continue to run searches for their clients, public users could run their own searches (and not see agent-only information), and that we were planning wisely for future work.
We focused on this initiative and released incremental changes over the course of almost three months. Now, the search criteria engine allows the system to perform searches in a UI-agnostic way. It houses all our rules and APIs in one easy-to-use spot (which also makes it easy to diagnose when bugs are reported) and is scalable for the future. Our customers never noticed (which was a good thing!) but investing in that area sped up our development of many other key features that rely on the search engine.
Not only did our velocity increase for future projects, but the team morale and confidence in our code also dramatically increased. As we’ve taken on new initiatives and worked on various features, team members have said “This will be so easy now! I can’t imagine trying to do this a year ago.”
ONGOING MAINTENANCE
Neither “Stopping the line” nor refactoring is a one-time event. Much like owning a car requires regular oil changes and maintenance, your code base and your teams require the same. Maintaining high standards, communicating openly within the team, and illuminating areas of the code that may require attention sooner-than-later will help reduce the cost of future work.
Here are some tools that we use:
- Frequent Discussions: We don’t wait until a designated day/time to groom or plan; we call a meeting as soon as we find that we need to collaborate – sometimes this is before work begins and sometimes it’s while a feature is being developed or tested. Sometimes, the meeting involves a Product Manager laying out a vision for a feature and providing insight into user behavior/expectations; other times, it’s a technical discussion for how best to write the code. But in every case, there is open communication and collaboration.
- Tech Check Ins: Teams meet with the software managers at least once per quarter to go over the previous quarter’s work and to evaluate upcoming work. One goal is to ensure that knowledge is shared about completed work as well as preparing for upcoming work. Risks are outlined and opportunities for refactoring are openly discussed. Another goal is to openly discuss feasibility of pulling new work so the Product Manager can adjust priorities accordingly and/or we can include the cost of the refactor in the cost of the feature.
- #release-tech: Because we have many squads that are focused in different areas of our product, we use a Slack channel to share regular code/tech-related updates. This is an opportunity for knowledge transfer about things we’ve learned, updated patterns and practices, etc.
- Retrospectives: We have both team-wide retrospectives as well as smaller squad retrospectives at regular intervals. These are opportunities to speak up about what is going well with our processes and what we should consider improving. The goal is to build psychological safety across team members as well as an open space for reflection.
Read more about how we build quality into our code here.
It can be scary to stop (or even slow down) releasing new features. But when you take the time to invest in a strong foundation in your code and within your team, you are making an investment for the long-term through increased velocity, increased confidence in the code, and an overall higher quality product. Make time to sharpen your dull axe – it will pay off.
