How do you want to improve for 2024 as a mobile engineer?
In this newsletter I want to share some ideas, with the aim of helping you enhance your skills as a mobile engineer in 2024.
Going against the grain, I often disagree with “standard” approaches; I stay away from UI architecture discussions, I don’t use TDD, don’t like SOLID, and don’t put all my dependencies behind an interface. Read on to discover more.
Learn about why UI architectures don’t matter too much
We developers like to squabble a lot about “the best” UI architectures.
But, in my opinion, UI architectures ideally are only a tiny part of an app architecture.
What often is important, is to avoid putting too much business logic in the UI layer.
Imagine your features as a Command Line Tool. When your feature can work there, it can work on any platform and UI architecture, making it extremely portable.
Yet, we often get carried away by starting in the UI layer because we often start with a “UI-first” approach, which can often be detrimental. Which means we get sucked into UI architecture discussions or finding “the best architecture”.
To learn more, read this blogpost and check out chapter 9 & 11 of the Mobile System Design book.
Why I don’t care much about TDD and SOLID.
The market is saturated with articles and LinkedIn posts praising TDD (Test-Driven Design) and SOLID principles. I might be an outlier; However, based on my experience, I seldom find the need for these techniques.
However, instead of complaining about it, I wanted to show you how to do it differently using something I call “Holistic-Driven Development”. The idea behind that is that you can work very fast with a sketching mindset. That means that you wait with writing tests, because in this phase you would throw away a lot of code (and also tests).
Instead, take extra time to design your API’s, make it work, then write tests afterwards.
You can find more about this approach in chapter 3 of the Mobile System Design book.
Regarding SOLID; I am finding it becoming outdated and more reflective of subclassing-heavy architectures. Nowadays we work more declaratively and we tend to favor composition over subclassing.
One negative side-effect of SOLID is that it somehow spawned a “Every dependency must be behind an interface” idea, which makes — in my experience — a codebase unnecessarily convoluted.
To understand its detriment, read more about this in Chapter 4. System-wide testing; Delivering higher quality apps and Chapter 6. Dependency Injection foundations in the Mobile System Design book.
You can also check out this article on my blog regarding interfaces and testing.
Another issue I have with SOLID is that the “Single responsibility principle”, is, ultimately, subjective. Yet it’s used a lot as arguments in code reviews (I was guilty of this, too). But, in reality, a codebase rarely consists out of components that all “truly” have 1 single responsibility.
To learn more, check out the book SOLID is not Solid for more information about why SOLID isn’t the be-all and end-all of approaches.
Testing best practices: Are you sick of them yet?
It's understandable if you're weary of the myriad ways people claim 'This is the best way to test your code.'
Having said that, I do find that testing books/posts/articles often don’t take a mobile context in mind. Because when releasing a build, with mobile we are often constrained differently than backend engineers. We can’t quickly rollback and “uninstall” apps from people’s devices. Rolling back is not ideal, but it’s not really an option we have as mobile engineers.
This impacts the way we release code, which impacts the way we check the quality of our apps. Which, again, impacts the way we test our code.
Feature-flags are one way to battle this, but it’s not the only approach.
I’d love to read more about testing in a mobile context.
That’s why I also want to offer some perspective with something called ‘System-wide testing’. A way to get more quality guarantees earlier on in the testing process, which fits well in a mobile environment.
Read more about this topic in Chapter 4. System-wide testing; Delivering higher quality apps in the Mobile System Design book. Alternatively, check out my article Shift-left testing approaches.
Get better at code reuse and delivering reusable components
Code reuse is one of my favorite programming topics. It goes extremely deep and dives into naming, abstractions, modules, API design, and predicting the future, asking yourself “How useful will this be for others?”
Abstractions are a difficult thing to balance, because by adding abstractions you risk overengineering your codebase. But if you do it right, you save yourself (and your team) tremendous time, making you highly productive.
As you may have noticed, this topic bleeds into almost all chapters in the Mobile System Design book.
To read about this specific topic, check out my article ‘Deliver reusable components without making them reusable’ and/or check out chapter 10. Delivering reusable UI views; The art of decomposing a design from the Mobile System Design book.
2024 and onwards
I wish you happy holidays and I hope that you get that job/promotion/role you want for 2024!
To support you, I am offering a 15% discount on the Mobile System Design book.
Use the code HAPPYHOLIDAYS at the checkout on mobilesystemdesign.com.
See you in 2024!
Tjeerd