10 Signs of Technical Debt in your Android app
Technical debt creeps up into our software projects. Sometimes we notice it, sometimes we don't. But the debt is obvious when you're the new person on a project and you're trying to make sense of it all. Android app development is prone to the same symptoms all software development can have. General signs like:
Inconsistent code style
The most noticeable are variations in indentation, argument wrapping and naming notations.
Inconsistent naming
Difference names for the same thing, like having classes named Service, Manager, Helper, Getter and Provider doing the same thing: fetch something from a database.
Lack of automated tests
Testing is a complex subject and having tests missing might point to other factors. But usually you can tell the least loved parts of an app from their lack of tests.
But there are Android specific symptoms we all have seen before. The ones that make us take a deep breath before continuing. Here’s our top 10 signs of Android development technical debt:
1. Not compiling for the latest SDK
Or building with the latest build tools.
2. MultiDex enabled
Do you really need all those libraries, like Guava or the full Google Play Services suite?Do you know why you need each library and if they are still in use? Which leads us to...
3. Two or more libraries for the same purpose
Picasso and Glide, Retrofit and Volley… just pick one of each.
4. Stuck on an outdated version of a library (or worst, a jar!)
We know libraries can have bugs, but staying on an old version of a popular library is usually a sign of not enough maintenance.
5. Random crashes after using the app for some time
Crashes like OutOfMemory are the consequence of cumulative bad decisions. Those decisions aren’t noticeable individually, but together make the application fragile.
6. Long Activities
Who hasn’t seen them? They always start small, but as the project grows, features pile up creating monster Activity classes. And nobody had the time to break them down into fragments or custom views.
7. Layouts with repeated sections
“I’ll just copy this section over here...”. Building reusable layout components with custom views and styles takes effort, but it saves time in the long run.
8. Disorganized values xml files: colors, dimens, strings
Lack of organization makes it harder to reuse them and to tell which ones are no longer used.
9. Copy strings inside code
That’s just lazy 😀
10. Multiple communications strategies
Communication between components is a complex challenge that needs many approaches. But you shouldn't mix callbacks, events and observables all in the same component.
At any given time, you will have 1 or 2 of these signs appearing on your projects. But if many become a common sight on a project, it’s time to pay back the Technical Debt. If you don’t, the code will continue to get worse on every change, bugs will increase and features will take longer to finish.
Want to do a more thorough analysis of your project status? Check out Karumi’s Android Audit guide list.