Perfectionism, Frontend Testing Giant Codebases, Scrum Masters?, When to Automate
Issue #25 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
📙CTO Diaries #16- Perfectionism isn’t that Perfect
But here's the reality: perfectionism, while rooted in good intentions, can become an obstacle to progress. Check out the recent edition of CTO Diaries, where our guest writer K Mohan, CEO @ Typoapp, talks about escaping the perfectionism trap.
Article of the Week ⭐
If you have over 50% test coverage from manual unit tests in a frontend codebase then you’ve over-invested in testing: you’re almost certainly slowing yourself down rather than speeding yourself up.
—Quentin Spencer-Harper, Meticulous CTO
Testing Frontend — Lessons from over a million lines of TypeScript at Palantir
Quentin Spencer-Harper used to be an engineering lead for Palantir’s frontend. Below are his insights into how frontend testing improved stability and quality in a giant typescript codebase with hundreds of engineers.
Getting testing right is the only investment that has the potential to double* your engineering velocity
Quentin observers that most of his team do not spend time “hammering out code”, instead without testing automation they spend a large amount of time manually testing for bugs and regressions, both visual and functional:
manual testing during writing
testing PRs and pre- and post-review
looking for root causes on bugs, regressions
All tiring activities that saps the team’s confidence. When teams lose confidence in their ability to make large changes, they refactor less. With less refactoring, quality degrades and the messes start to accumulate and get worse.
But here-in lies the main issue: tests alone aren’t enough. A clear testing strategy is the only thing preventing bad tests from causing even more slowdown. Due to overhead of maintaining the suites, especially end to end tests. Below are Quentin’s suggestions on how to clarify such a testing strategy.
* We’re still waiting for the proof of doubling engineering velocity, but it looks promising
#1: Unit tests: test the right sized unit, at the minimal cut
Carving out the right boundaries for the “unit” in unit test is what separates maintainable and easy to write use tests from messy ones. You may have heard the term “testing implementation“. It refers to testing configurations where there is a 1:1 relationship between the classes and functions and the tests.
The ideal test scope will be found somewhere in the middle between each function and the user-facing API, preferring stable API (interfaces) or one key hard-to-isolate component to serve as the nucleus for each such boundary.
#2: (Probably) don’t write Enzyme or component tests
Mounting React components in isolation order to test cover their behavior is deemed expensive and hard to maintain. However, in rare cases these types of tests do shine when testing a certain configuration of component hierarchies and their interactions.
Quentin stipulates that complex behavior worth testing can always be extracted to a unit level. Most engineers end up covering whether they used react hooks correctly, instead.
#3: Scalable integration tests: look for stable APIs in your app where the variation in the values passed through that API is the root of a lot of the complexity in your app
Integration tests are best used as a small maintenance overhead along integration boundaries. Usually a layer touching file systems or network (DB, 3rd-party API). He highlights an interesting point: focus on areas where variation in inputs represents most of the risk.
That is what is worth isolating and testing.
So what tests are worth writing?
Unit tests for sufficiently complex (composed) logic
Integration tests to capture variations of input when they touch a file system or network boundary
E2E and smoke tests to serve as a high-level last line of defence and early warning.
Other highlights 👇
Are Scrum Masters Too Much Overhead?
It seems no one wants to hire Scrum Masters. Do you?
Maarten has a lovely tale to share from his experience playing Ultimate Frisbee. In Ultimate Frisbee every player is their own referee, essentially crowdsourcing the rules of the game with plenty of redundancy.
He uses this example to balance the two most dominant arguments in scrum teams:
Scrum is crucial, everyone should focus on learning the rules as it is the key accelerator for a Scrum Team
Scrum is not important, scrum should fall into the background in favor of a better process that the Scrum Team discovers by collaborating
If you’re constantly discussing the rules of the game, what they mean, and how to interpret them, then the game will be ****.
If the team focuses on Scrum and has an SM, the SM will take over as referee. This creates an incentive for the team to not know the rules and self-manage.
If the team has no interest in Scrum and has an SM, the SM will frame business and engineering discussions into a scrum perspective, blurring the lines between process and product engineering. A sort of tunnel vision.
Scrum Masters make themselves redundant?
Marteen argues that needing an SM is the underlying root cause for the behavioral anti patterns. Perhaps scrum’s biggest flaw is that it is designed with a Scrum Master (Coach) in mind. This makes the team topology extremely complex.
Rather than small teams wearing multiple hats: 4 people with 10 competencies to make the team skill complete, supported by platform teams, the scrum master eludes definition and bloats the team structure, often also taking on a managerial role.
When to Automate?
Original title: The importance of data when making decisions in the engineering industry
Alberto Gonzalez Rosales guest wrote on Engineering Leadership on data driven decision making. His example shows how to compare choices and formulate an objective, low-latency decision to eliminate biases:
Works in DevOps, notices jobs in the work queue stuck for days
Gets them unstuck by dequeuing manually
Is anyone else wasting time with manual dequeing?
Findings: “The number of dequeued build sets amounted to 8% in the last 100k build sets. That means that 8% of the time, someone needed to manually dequeue the job.”
Now the calculations! 8000 jobs get stuck for more than 35seconds on average, which is 77 hours wasted. 77 hours of developer time can be put on a chart and touches the bottom line!
Go/no-go? We are saving 77+ hours of manual tedious work with the 8-hour work by creating an automation (cron job to dequeue).
Even with potential tweaks and maintenance this seems like a good tradeof. Have you found similar decisions being made in your team(s)?
Find Yourself 🌻
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week(end), Ciao 👋
Credits 🙏
Curators - Diligently curated by our community members Denis & Kovid
Writers of the week - Alberto Gonzales Rosales, Quentin Spencer-Harper, Maarten Dalmijn
Sponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.