Date: February 12, 2016

When you hit a wall (or a bug) in your current android project…CHILL (Don’t Panic/Freak out)!!!

Because when you freak out you do too much at once which won’t help you narrow done the problem and isolating variables is key at this moment in time. You need to take a long at your work and do a binary search on it to narrow it down. Here are some general guidelines.

– Assume the bug is yours not Android’s or your partners or the library’s/system’s etc

– Reproduce the bug: if you can reproduce it in manual ways it means you can reproduce it in an automated way.

~ Does it recreate reliably? (In different environments, different phone models and carriers, etc)

~ If so, next step! Easy!

~ If not, then you’ve got a real problem in your hands. Everything else will be a bit more difficult but the steps are generally the same moving forward.

1. Understand

Create a bug report in your mind. Get yourself organized and familiarized with the bug.

• What do you expect to happen?
• What is actually happening?
• Why might there be a discrepancy in this?
• Are your assumptions wrong?
• Do you have the wrong object?
• Is your view misplaced?

2. Find

Where are the problems?

• Some value is wrong somewhere
• Where is the value modified?
• When you step through your code, does your value change as expected?
• Why isn’t it changing as expected?

3. Fix

By now you should know:

• Whats wrong?
• Why is it wrong?
• Where is it wrong?
• Maybe when it’s wrong? (Under what conditions)

So the next step will be “easy”

4. Just change the behavior to fix the problem (you know after a lot of problem solving but we will skip that part because every problem is unique)

Then ask yourself:

• Did you actually fix it?
• Did you create new bugs? (Test Test Test)

5. Solve it efficiently

It may be faster to add code to recreate the conditions of the problem. Don’t introduce new problems by altering your code if you don’t need to. Especially code that has been tested and is already working. Alter code only if needed. Also remember, you might break other people’s code if you alter code prematurely.

Sometimes, the bug is simply an oversight: Common Questions to ask yourself…

• Is your variable null? (It happens)
• Does your object have the right properties?
• Are you getting the right object?
• Are your assumptions wrong?

If you absolutely cannot figure it out or cannot reproduce the bug…

Check:

• Your Network connection (although ideally, your app should still work without one and/or alert the user of the change in functionality because of the lack of a network connection)
• Your threads and how you’re handling them, it could very well be a threading issue
• Maybe it’s a server error? (Don’t ever default to this)
• Maybe it’s a time-related bug which only shows up at certain times of the day or certain minutes of the hour or during a change in location
• Hardware
• Current framework version
• Ask someone else for insight

One of your testing phones should always be a Samsung because these tend to break your code a lot, a lot!

But… Sometimes it is out of your control 😦

• The library could be broken and if that’s the case… File a bug report! Give back to the community by making sure people are aware of the issues and have a chance to work on them. Although awesome people write these libraries… sometimes they don’t maintain/keep up with them

Ask yourself:

• Is it open source? Can you fix it directly?
• Last Resort: Is there a workaround?

Workaround(Hacks)

or… “Treat the symptoms and not the problem”

Always fix the problem if you can unless…

• There is a critical time constraint (blocking someone or a demo deadline)
• Or you just really can’t fix the problem (it is out of your control)

Note a workaround postpones the problem (which == Technical Debt)

Technical Debt: You are telling the machine what to do but you are also communicating with the people who will work with your code in the future. Realistically, this could very well be you and future you thinks current you is the worst programmer ever, and you will have to deal with this technical debt later. If not you, then someone else so try to avoid this.

 

Author: Madelyn Tavarez