The bigger picture
I read “The Truth about Preventative Optimizations” yesterday and again I found myself in this weird position of agreeing with the argument, but (still) disagreeing with the problem.
I agree with the high-level idea. You shouldn’t knowingly write sub-optimal code and if you can avoid problems down the line by just being careful with some simple elements of style and architecture, you should definitely do that, as long as it doesn’t affect code clarity. For example, using a StringBuilder is not a micro-optimization, it’s just good programming.
I also agree with the fact that too many devs seem to take the famous premature optimization quote and use it as a catch-all excuse for completely ignoring all optimizations until it’s very late and their users are complaining.
Finally, I agree with the fact that the advice that came from Google since the last I/O regarding memory optimizations has some really good tidbits and probably every Android developer has something to learn from reading those posts and watching those videos.
What I disagree with though, is the posit that this type of memory conservation and trimming is a major concern for most app developers out there. Removing enums from your app code is not a premature optimization, it’s a micro-optimization: too little benefit versus the cost, in a “real world app”.
I have met more than a few Android developers over the years and I have seen my share of code-bases as well, and I find it very difficult to believe that for most app developers waiting for advice from Google on how to build better apps, this even comes up as a concern. I don’t want to say it never does, but I have never heard it come up, nor faced it myself or on any of the teams I’ve worked with.
I can’t speak for any other developers and definitely not for the community at-large, but this is what I think was a big issue with the advice and why feathers were ruffled. Arguing that it’s not a premature optimization misses the point entirely. Even if it’s not premature, even if these are fantastic preventative fixes, they fix a problem that for most apps and teams is pretty much invisible, dwarfed by many other more urgent and much more terrible issues: testability, memory leaks, bloated activities, keeping code-bases lean and flexible etc.
These are the problems discussed in team meetings.
These are the tracks at conferences everywhere.
These are real issues that teams are still struggling to fix. And they are so much more impactful that we are willing to compromise on other smaller problems, like the memory footprint for enums, if we can even slightly improve any of this.
When the team behind Android publishes advice on how to write apps, dropping enums to save a tiny bit of memory is not what I was expecting to read about. I mean, how often do app developers run into memory problems caused by enum-bloat rather than bitmaps or memory leaks?
I’m not surprised at all that many developers felt frustrated with the “enum” advice, because it seems so disconnected from the problems they are dealing with day to day.
It’s great that the Android team has taken on the effort to put out performance advice, in writing, podcast and video. It’s a great initiative and the effort shows. I appreciate it and I think everyone did also.
I don’t think people are upset or disappointed with the advice itself, as much as I think people are upset with the presentation of the advice which is also telling developers what their problems are. They don’t need to be told that, they know their problems well enough and what they need is help with exactly that. Had this been phrased as “if you are trying to reduce your memory footprint, here are some things you could try”, I think the response would have been much different. But the way this advice comes, it appears to ignore the elephants in the ecosystem.
The community is working on a memory leak finder, on porting a better date-time API, on testing frameworks, on dependency injection, and so much more. They are shouting their problems out loud and clear, they are fighting day-in and day-out to ship better apps faster and that’s where help from the mothership is most welcome. Advice on how to save a few kilobytes of memory not only doesn’t help solve these issues, but it seems like it entirely ignores their real needs and concerns. That’s what we’re trying to attract attention to. That’s the disconnect that needs to be bridged. That’s the bigger picture.