I recently tried to perform an optimization on one of the projects I am working on. It was a simple one-line change, but it took me forever.
That was an optimization regarding Compose Stability. I had two modules that use compose, one of which is dependent on the other, while both are published as different libraries.
In compose, if you have a dependency on another module, all classes from that module are considered unstable unless you add the compose runtime there to infer or mark it explicitly as stable.
And here comes the optimization; we were heavily dependent on one class in our composables from that module, so adding such optimization will increase our composables performance by a great margin.
So, it's a one-line change only, right? I'm adding just the dependency of Compose runtime! So it might take me only 5 minutes to add it and cross-check the optimization using Compose compiler reports.
Unfortunately, it took me more than 3 hours π’.
Why is that? It is because, as developers, we make a lot of pre-assumptions, and we build on those pre-assumptions many things, and if those are faults, then everything built on that is wrong.
Here is exactly what happened: I added the stability marker and launched the report task, and the report said that the class was still unstable!
I made all the sorts of things that maybe would go wrong; I checked the compose versions, the kotlin versions, checked the stability inference itself (maybe compose developers were wrong), basically everything that came to my mind! Still no results.
The only thing I didn't check was whether I was depending on the module I have changed π.
What happened is that the dependee module was using the published version of the dependent module, so every change I made in my project was local because my assumption was that I was using implementation(project())
and not implementation(")
.
Why did In't verify that first? because my mind didn't even think about it, even though it is the default option there.
And this brings the question, how can we make sure we don't depend on our default thoughts?
I believe this is normal in developers' lives, and later on, we will call this Experience, but still, we need a way not to make our minds assume such pre-assumptions without our permission.
Would you think about doing that if you were in my place?
π‘ Tip of the week
This week, try to verify the assumption you already think they are correct! Is an internet connection available? Is the database open? basically, any simple assumption that you thing is present!
π£ See you in the upcoming weeks with another Tip!
βοΈ Charfaoui Younes.
β
My preferred things this week
Here is a couple of digital content Iβve been consuming this week:
π¬ My YouTube Video Debug Your Jetpack Compose UIs Effortlessly!
πΉ Video Content: Guide Refactorings With Behavioral Code Analysis
πΉ Article: UseCase Red Flags and Best Practices in Clean Architecture.
π Book I am re-reading: Code that Fits in your head.
You would make my day if you share this newsletter with other developers π.
π€ Here are other ways I can help you with:
π Work with me 1:1 - book a coaching or strategy session for 60 minutes.
π¨ Course: Refactoring Legacy Code Like a Pro: A step-by-step approach for refactoring messy codebases into a Software Masterpiece.
π₯ Check out my YouTube channel: Discover tips on Android, Software Engineering, and productivity for developers.