Beware the 1% Solution
Some Android developers (e.g., Jake Wharton) are at the top 1% of their profession.
Some locations (e.g., Silicon Valley) are at the top 1% of infrastructure (e.g., Internet access, clean water).
Some Android apps (e.g., Square) are at the top 1% of complexity.
It is important to remember that 1%-ers make up approximately 1% of the Android ecosystem. For every Jake Wharton, there are 99 others with less skill, less talent, or less experience. And, for every Silcon Valley/Alley/whatever, there are 99 other areas with fewer available resources. And, for every Square app, there are 99 simpler apps out there — some in the Play Store, some private for individuals, businesses, etc.
I bring this up in light of Jake Wharton’s post regarding Android build systems and follow-up tweet.
On the surface, what the post requests seems like goodness and apple pie. After all, who wouldn’t want an empowering, enabling, dynamic build system?
My concern is less about what the post requests as much as what costs the solution might incur. A solution that benefits the 1% at the expense of the 99% is good for the 1% and bad for the Android developer ecosystem overall, IMHO.
I work with the 99% every day – teaching, answering questions, and so forth. One of the reasons I do this is to keep me grounded, so that I keep the 99% in mind in what I do. Sometimes I fail in that, as I am very, very human.
Android already is pushing the envelope on complexity for the 99%. People turn away from Android development because they cannot climb the hill of the resource system, or slide backwards when the SDK deprecates formerly suggested patterns, or get stuck when the tools look different than they did a month ago, or any number of other issues. Much of the 99% have little Java experience. Some have little programming experience.
Much of what the core Android tools team — Xav and Tor and the rest — have been focusing on over the past year or so have been to benefit everyone (e.g., faster emulators) or to benefit the 99% (e.g., drag-and-drop GUI building). In their own way, they have been trying to improve Android development inclusiveness, and therefore have not been radically changing the build system, at least in terms of what the 99% perceive.
This is not to say that improvements to the build system should not be made, whether by a wholly-independent effort or by people contributing to the tools on the AOSP. However, if the core build system for Android is to change, please keep in mind:
-
Requiring more visible dependencies for starting development (e.g., Gradle and Groovy) is like requiring more permissions in your Android app — some percentage of your user base will decline to install and will move on to something else.
-
Requiring more setup to build your project (e.g., mandatory version control) may lose other developers who lack experience with such technology and get overwhelmed with everything they need to learn to create “Hello, world!”
-
Requiring reliable Internet access will be a problem for developers in areas where reliable Internet is a dream more than a reality.
And so forth.
Again, this is not a knock on what Jake Wharton asked for. I have absolutely no problem with having a better build system. Instead, this is a warning for potential implementations: make sure that changes are at least neutral for the 99% while they benefit the 1%, or can operate in parallel to a solution that serves the 99%.
After all, once upon a time, 1%-ers were members of the 99%.
(except for folks like Romain Guy and Dianne Hackborn, who were 1%-ers on Android before there was an Android… :-)