Only two more weeks until Daylight Savings Time arrives and most of us gain another hour of daytime here in the US and Canada (sorry, Europe, you still have a whole month ahead of you and sorry, Hawaii, Arizona, Saskatchewan and Yukon, you have forever ahead of you). Many people believe DST was originally created to give farmers an extra hour of daylight during winter mornings, so they could gather eggs, milk cows, and do whatever other twee activities they get up to in December at the convenient hour of 7am instead of 8. Do we need to update this system for our modern era and focus it on software engineers instead? A lot of devs feel more productive at night, so what if we changed it to “spring forward” 15 hours, making it pitch black outside at 8am? Maybe Ro Khanna can take this up in Congress and create the ultimate dark mode. Â
No matter how light or dark it is outside at any given time, the Flight Deck is here to share articles that discuss a future filled with write-only code that is never seen by a human, examine how GitHub Actions may be slowly killing your engineering team, and ask if there is such a thing as releasing mobile updates too fast and too often (among many other things).
Posts we liked
Swift bits: Transition vs Transaction
SwiftUI’s animation system has many very similar-sounding animation options. What, for example, is the exact difference between .spring(), .interactiveSpring(), and .interpolatingSpring()? Reading this article by Anton Gubarneko will not give you the answer to my example question, but it does cover the differences between Transitions and Transactions, two animations related to motion and state changes that serve very different purposes.
There is a growing concern that working with AI-generated codebases puts engineers in a position of “cognitive debt” where, at some point, the codebase grows so big that no one understands how it works. A kind of LLM version of extreme tech debt. But is it really worth worrying about? Did anyone understand how their previously fully engineer-generated codebases worked, aside from maybe the first couple of engineering hires, who the company pays increasingly more money to keep around and fix all the outlier bugs that pop up every two weeks? Nate Meyvis discusses this.
Write-only code
Continuing with the theme above, it seems as though we are barreling towards a future where an increasingly large amount of code is not written, examined, seen, or even thought about by a human at all. If code is committed to a Git repo, and no one is around to see it, can it cause a bug? Obviously, it can; it wouldn’t be code if it couldn't. How can engineers manage this future of coding? Joseph Ruscio examines software engineering’s long history of eliminating one bottleneck only to immediately encounter another.
We’re featuring a lot of articles with very short titles this month, aren’t we? Is this some new emerging software developer blogging trend I’m only now picking up on while I’m writing the newsletter? Putting this aside, can you imagine if everything in your life worked the same way as most apps do? If your car threw a modal over your windshield to ask, “Do you love driving this car?” as you’re merging onto the highway, and if you responded “yes” pushed another modal trying to get you to leave a rating on the car dealership’s website? You wouldn't like that very much. Mike Swanson talks about the slow shift from apps as a tool you operate to apps as a channel that operates on you.
Android modularization for large teams (and code bases)
When done wrong, modularizing your app can increase the sort of problems it’s meant to solve, leading to longer build times, more complicated testing, and less team autonomy. But when it’s done right can change your app from a “tangled monolith” into a collection of independent and rapid compiling components that are easier to maintain for the long haul. Cedric Ferry walkthrough how they approach this at TikTok.
GitHub Actions is slowly killing your engineering team
Ian Duncan was an early employee at CircleCI and has “used, in anger, nearly every CI system that has ever existed.” But there is one CI platform that makes him angrier than all the others: GitHub Actions. He understands why so many of us use it; it’s right there in GitHub, sitting next to all our code. Read why he thinks good enough is not nearly good enough for CI.
Go figure
On average, mobile engineers spend 5 hours per release on non-productive or low-value tasks: manual steps, coordination issues, approval bottlenecks, and other busywork that doesn't move the product forward and leaves many team members a little annoyed.
Assuming a biweekly cadence, five wasted hours every two weeks translates to 130 wasted engineering hours annually. That's more than 3 full engineering weeks lost to process inefficiencies and not spent on building features that users care about.
‍
This was just the average of course. Many teams pour more than 5 hours per release into these tasks. Learn more in our State of Mobile Release Management report.
Posts we wrote and videos we recorded
Mobile release management: How to waste 19% less time & ship 14% faster
Using data from tens of thousands of real mobile releases, we examine how better mobile release management can in turn improve time spent in releases, time to recovery from unhealthy releases, product lead time, on-time release rates, and app quality (not everything is about being faster or saving time). We also dig into the gains teams that focus on release management see compared to top-charting apps.
Is there such a thing as releasing mobile updates too fast and too often?
Can your steak be too juicy, your bread too warm, your lobster too buttery? Expanding on the aside above about how not everything can be about speed or time-savings, is it possible to go so fast and ship so many updates that it becomes a bad thing for you, your app, and your users? Well, it depends, and Pol Piella looks at why.
Runway featured feature
In case you missed it, a few weeks ago we released Flightpaths, an entirely new way to set up, manage, and automate your end-to-end release cycles in Runway. Read our detailed announcement.
Every mobile org has its own unique shape and way of releasing. Whether you ship native Android and iOS, cross-platform, multi-platform (e.g., mobile and wearables or TV), or white-label (with dozens or even hundreds of apps to get out the door), mobile release complexity compounds. At a certain scale, subpar — or even “just fine” — release processes and tooling have a real negative impact on your team.
Flightpaths is a complete re-architecture of the platform, designed for flexibility at scale, unlocking more complex release workflows and new ways to unify and take action across multiple apps at once.
With, Flightpaths you can monitor all your apps and releases in one place, take actions in bulk across all of your apps as needed, customize every step of your release process to match your team’s own unique approach, and define a release blueprint from one app and apply it to any other apps that you want.
Our goal is the same as it’s ever been: help mobile teams release their apps with less wrangling and safeguard app quality in the process. Now, Runway is positioned to deliver this for even more use cases and to enable teams to get even further down the path to mobile release excellence.
Events
We’re counting down to April when we’ll be sponsoring three conferences across the world at almost the exact same time. Thankfully everyone on our team likes to travel. Come see us at:
- Android Makers (Paris) - April 9-10
- try! Swift Tokyo - April 12-14
- Deep Dish Swift (Chicago) - April 12-14
As we all gaze longingly out the window in anticipation of our April travels, pass the time by reading one of our previous 29 newsletters.
