If you use OOP than this looks like your code:

and in Android it gets worse in the Activity and other classes with views boilerplate, etc mixed in. If we are willing to change our workflow, dev techniques, and toool integration we can have this:


Guess which is easier to analyze and maintain? Yes, its true you can get some development time savings by adopting to new tools like LessPainfull or other instrumented testing in the clouds android testing solutions. But, the amount of time savings is not that much because as your accuracy of test results increases so does its effective use which increases your dev time as you make sue of those results,ie you get a huge increase in QA quality for some inceases in devtime.

If you separate out the concerns rather than just inject them we should see a decrease in development time as code libraries are built up as some of the cost savings wil occur when you re-factor the libraries you are using to separate concerns. Iteration-wise it should allow any android developer to push out iterations of an android application faster than they have did such development work before by at least a2 to 1 factor.

Now, of course if you are a start-up you could get the android developer candidate that looks pretty on a resume for the HR department to gleam about or yo cold just maybe pay attention to technical and development debt and get the android developer that develops new techniques and processes and tools to solve both short-term and long-term problems.