Many indie developers think they can get away with introducing hacks all over the place while developing an Android application. Those shortcuts do speed up development. Probably, they’ll even take you closer to the launch day.
However, chances are that they’ll end up doing more harm than good.
The main reason is pure technical debt. Technical debt makes reference to the work that remains to be done in a project in order to consider it complete. All those hacks contribute directly to it.
As described in a a CAST report, the technical debt is like a ticking bomb:
first, it doesn’t go off with a bang, it’s more a slow burn. Change starts to take longer… and operation costs start to spiral — it will not be a single cataclysmic event; it will be death by a thousand cuts.
In this list, we’ll attempt to classify the different types of technical debt, sorted by how much damage they inflict:
- Choosing the wrong technology for your platform. Migrating to a different technology usually implies changes at many different levels, plus learning the new platform. A very costly process. This doesn’t usually apply for an Android app, tough.
- Designing the wrong architecture. If the architecture does not fit the problem it intends to solve, extensions become more and more cumbersome, until a major rework may remain as the only alternative to scale. This is usually a huge task to tackle. This applies for big applications, where several layers communicate to each other.
- Error-prone code. Code that is hard to understand, and thus expensive and dangerous to modify. Also, difficult to extend. It was perhaps originally done badly, or it worsened with subsequent modifications. Many of those hacks fall within this category.
- Code that is difficult to test. If it is difficult to test, chances are that it falls in both the previous (Error-prone code) and the following (Poorly tested system) categories. Testing costs tend to go up with future changes, which just makes things worse. Remember that even if you don’t create an Android Test project, or you don’t do GUI testing, you can still write traditional unit tests for the critical modules of your application. You’ll be glad you did.
- Poorly tested system. This leads to the classic
I fixed X, but broke Y by mistake. No tests warned you about it. As a consequence, one tends to become lazy when it comes to improving the design: attempting to refactor a poorly tested system is scary. On the other hand, a well-tested code base provides you with confidence to improve things with a higher expectation of succeeding. After many releases, the time spent doing manual testing (aka click around before the release and hope everything works as it used to) will surpass the time it would have taken to write proper tests in the first place.
- Duplicated business knowledge. if the DRY principle is applied successfully, a modification of any single element of a system does not require a change anywhere else. Often, the “rename” operation is expensive and extremely error-prone. In practical terms, your constants are defined in a single, central location, right? How about your assumptions about what extras your activities accept, or the data format you use for storing data into persistent storage?
- Missing or poor error handling. Does your application let Force Closes happen? Or even worse, does it catch exceptions and try to go on as if nothing had happened?
- Inefficient implementation. Isolating the bottleneck, profiling and fixing it is not an easy task. If your application is a service, do make sure you won’t drain the phone battery. You really want your applications to feel responsive in all supported devices.
- Code that works, but nobody quite understands why. Usually somebody that left wrote it, and it’s been running untouched for a long time. Sooner or later, somebody is going to have to fix it or adapt it to whatever external change. That may be expensive in terms of time and frustration.
- Outstanding bugs in code and unresolved static analysis warnings. It depends on the severity of them. However, many of them may have been there already for a long time, and didn’t cause any real problems yet. A cheap fix.
- Duplicated code. This is one of the first things that comes to mind when discussing technical debt. One of the star features of static code analysis tools. But, how bad is it? In a given codebase, there may be several versions of some assertContains method. Sure, we’d be better off if they were in some commons library. But how much harm do they do, in terms of maintenance costs? I’d argue it’s not much.
- Outdated documentation. Out-of-date documentation can lead you in the wrong direction, when it claims things that don’t hold anymore. Write little documentation, but make sure it is close to the code, and up to date.
- Bad style: magic numbers, missing comments, wrong indentation, … Untidy code is more tedious to read. But this is trivial to fix. (By the way, fixing the formatting is fine as long as it is not done in the same changeset as a change in the actual logic.)
The point is, use your limited time in the most effective way. Fixing all warnings feels good, but, does it help that much? Did you make sure your design is scalable?
Talking about scalable designs, we pretty much killed our suite of News Reader applications because of a few bad design decisions. Long, long time ago we launched AnyRSS, a simple, widget-based RSS reader. It is the parent application for several other single-RSS readers, such as FML. They were great, the CTR in both Admob as well as Mobclix for them was really high, compared to our other applications. As you can imagine, all these applications share almost all functionality. But the architecture was just not right.
We are definitely not doing the same mistakes with Chat Toolkit and Smileys For Chat. The setup is similar: several free applications perform upselling to a paid one. Not a single line of code, not a single string, is duplicated (well, almost). Several module libraries collaborate to create these applications, and they have well-defined responsibilities and APIs. Coding new features is just so easy as doing it on top of a Hello World app, and most modules have a way of running in stand-alone mode.
There are other reasons why you want to keep a well-designed, clean, clearly documented codebase. What if you want to bring in a contractor to help you out? Will it be easy for them to get up to speed? Or is it just impossible? Can you give them one single module on which to work, or is the whole code a piece that can’t be easily decomposed in subpieces (i.e., different JARs)?
Also, are you proud of your code? Would you publish it into GitHub? Maybe at some point you want to have some of your code published while considering a job change? But, is it good enough to be out there in the open?
Some interesting articles we have checked out in order to write this post:
- Technical Debt – How much is it Really Costing you?
- Technical Debt on Java DZone
- Monetizing the Technical Debt on InfoQ
- Technical Debt on 10x Software Development blog