Retro: What We Learned from Our Migration from LESS to SASS
In software, building is a costly way to learn; redesigning is even more so. A migration from LESS to SASS taught us critical lessons on balancing redesign needs with effectiveness and user value.
Redesign This, Redesign That
Redesigning software can be essential, yet it demands considerable resources, affecting timelines, budgets, and team focus. Back 10 years ago, our CSS migration revealed how such projects, though aimed at long-term improvement, also introduce immediate complexities.
Time and money costs: The redesign required more developer time and attention than anticipated, stretching over several months and forcing us to defer other projects. Unexpected resource drains like this affect team productivity and may lead to postponing marketable new features that real customers are waiting.
Risk of Introducing New Bugs: Switching to SASS brought unforeseen integration issues. For example, users on the Product Detail Page (PDP) encountered colour-switching bugs due to CSS dependencies not accounted for in the SASS setup. This instability spread across the site, turning small fixes into major debugging sessions. Tackling these bugs became a recurring and time-intensive challenge, revealing the unpredictable and often hidden interdependencies within the codebase that redesigns can uncover.
A surreal journey through the complexities of software redesign, where unexpected interdependencies, hidden bugs and transformation of a new code landscape.
Our Journey Through Challenges
While we aimed to improve efficiency, moving to SASS impacted other previously stable components. We found that styles we assumed to be isolated were actually interdependent, causing more errors. Delays piled up, and halfway through, it was clear our original timelines were optimistic. However, the team stayed dedicated, working professionally to push forward, despite the increased pressure.
The Initial Expectations
We saw that LESS was getting stale, most of the community of developers using pre-processors were moving to SASS/SCSS. We thought are UI “iceberg” was melting as the book from Kotler would describe in Our Iceberg is Melting. We were scared and we needed to bring change, assuming we need it right away. We started with the team’s initial vision and assumptions going into the redesign of the UI experience for internal development and partners that would love our new code. We discussed with senior leadership how to make it have, provided expectations about timelines, team allocation and prepared sessions to identify complexity. We identified the Product detail page (aka PDP) as the most important part to modernise with high customer impact once delivered to encourage teams to extend and customise the eCommerce solution.
Unforeseen Interdependencies
Switching to SASS brought unforeseen integration issues in the PDP, that was contained in the overall structure of the page.
In addition to that we discovered multiple CSS interdependencies that weren't apparent initially, complicating the project more than anticipated. As we transitioned from LESS to SASS, styles that seemed isolated began affecting each other in unexpected ways. Global styles from the LESS setup conflicted with new SASS styles, creating issues like unintended layout shifts and visual bugs. For example, the Product Detail Page (PDP) relied on a stable global style for color-switching functionality, but the SASS migration unintentionally broke this interaction, leading to a frustrating user experience.
These cascading dependencies highlighted the risks of working in a tightly coupled system where changes in one area impact seemingly unrelated sections. Small changes in one module or component triggered changes across the project, leading to a cycle of bug-fixing and retesting. This experience underscored the need to map dependencies more thoroughly before undertaking redesigns and the importance of isolating styles to prevent similar leaks in future projects.
Escalating Delays and Project Pressure
As the project unfolded, delays in the cycle of release of isolate SASS began to compound. Every new bug or styling conflict required additional debugging, which added days. What initially seemed like a manageable redesign spiralled into a series of setbacks. Each delay affected timelines for other features and normal bugs to be fixed, putting pressure on team members and forcing us to slow down in the migration to stay put to other important tasks.
The mounting timeline began impacting team morale as well. With each delay, the pressure to deliver a stable redesign increased, especially as some feature releases were postponed. This created a cycle where team members felt pulled in many directions, what is more important to fix a bug in the current PDP or try to prevent it to happen in the new one? Additionally, the partners couldn’t use the new PDP without upgrading the existing projects adding external pressure to the release cycle.
Reflecting on this experience, we recognised the importance of building flexible timelines for future redesigns, accounting for the possibility of complex dependencies and bringing together the partners that were customising the existing features
Resilience and Team Spirit
Throughout the project, the team faced pressures and frustrations as they dealt with unexpected bugs and delays in the timeline. Despite these challenges, team members showed resilience and professionalism, remaining dedicated to completing their work and asking for help across the department. One strategy that helped sustain morale was regular, open communication; frequent check-ins, in person at the time, allowed team members to voice concerns, celebrate small wins, and stay aligned on progress. This approach fostered a supportive environment where everyone felt heard and valued despite the difficulties.
To maintain productivity under stress, we also broke down large tasks into smaller, manageable releasable goals, allowing the team to experience a sense of achievement and progress. We would reprioritise bugs as needed to keep the focus and retrospect every two weeks to identify improvements in the process. When setbacks occurred, we focused on solutions rather than placing blame, reinforcing a collaborative atmosphere that empowered team members to tackle problems creatively and maintain a positive outlook.
We laughed saying: here we don’t do BDD: Blame Driven Development
In reflection, these strategies not only kept morale steady but also strengthened team cohesion, helping us navigate the project’s challenges more effectively.
Key lessons learned
Remember that redesigns have high costs, like our LESS to SASS migration are resource-heavy, requiring more time and focus than expected, and often defer other projects, delaying new feature development.
Scout for hidden interdependencies: dependencies can surface unexpectedly, creating bugs and complex issues across the system. Mapping dependencies and isolating styles is critical for smoother redesigns.
Have clear principles to define flexible timelines and trade-offs: anticipate setbacks by building in time buffers and prioritise what’s essential, allowing for complex dependencies and maintaining flexibility.
Commit to team resilience: Regular communication, solution-focused retrospectives, and manageable goals help maintain morale, productivity, and cohesion, even under pressure.
At the end of the day, as Bernández once wrote in Para recobrar lo recobrado (to recover what has been recovered), one becomes "more luminous" after hardship, as both joy and sorrow shape a richer experience of life in the same way the tree bears fruit from what’s rooted beneth.
