It’s easier to ask forgiveness than it is to get permission

Until recently, I did not like this phrase. It was used by people to do all sorts or random things, and it is a phrase that people could use to condone their misdemeanors. It is even more difficult for people like me to digest, who want a reason behind any change or decision.

However, as soon as you step into the IT world, or the world of any business, it starts making a lot of sense. Let me explain.

In the past, an industry had two ways of approaching change. They would seek change,  and try to do something drastically different. Sometimes this resulted in miracles, but more often than not it would result in failure. As a result of this, they would shut themselves from experimenting completely, because there was too much to lose. Failure was costly. Then they would reach a point where they realised that they have been closed to change for too long, and would then want to change everything. The cycle would then repeat.

Recently, people started realising the value of controlled change through experiments. That, to me, is the only sustainable way of making change over long periods of time. One of the most popular texts on that topic is The Lean Startup. This way of doing things has become popular in the software industry recently, but it has existed for a while in all domains. In fact, this methodology of conducting experiments and adopting the right path by measuring results has been the basis of all modern science.

There are two ways of adopting this approach. Both approaches are listed below.

The first method. This should be used when you have a hunch that a new product, feature, process, or change would be useful, but are not sure:

  1. Think of what you want to achieve, and create a hypothesis on what approach could help you achieve it. So far, you can only make a guess on whether this approach will work or not. This is your experiment.
  2. If you feel the approach might have even a slight chance of success, try it out. You can do it in a small step, or with less resources, or try it on a small set of people or systems.
  3. Measure whether your experiment was successful or not. Build on it if successful, modify or revert if unsuccessful.

The second method. This is for scenarios when you have multiple ways of doing things, but are not sure which one is correct:

  1. List down the approaches that you want to try, and pick the top two that you feel have a chance of success.
  2. Try the two things on different people, systems, or times. If you have two ways of showing the dashboard, show one way to some users, and another way to another set.
  3. Have a way to track what works better. This could be qualitative or quantitative.
  4. Go with the one that gives better results.

I was a part of a team where change was difficult. People were scared of change.  I realised that if 4 out of 5 people were okay with making a change, and the other 1 was quite vocal about not changing anything, the 1 usually won. The only way out was to make a small change, and see how people react. Often, the reaction would be okay if the change was wildly successful. If it failed or was partially successful, it got people flustered, and the change got reverted.  This way, the change got reverted more than half the time, but there was still a higher chance of it going through.

In conclusion, it is easier to analyse than to predict. Design an experiment where change is fast, and easily measured. Mark it as success or failure, and move on.


The Value of Prioritisation

One of the key lessons I’ve learnt in the last year is the value of prioritisation.

The modern workspace has many things going on, and we have very little time to catch our breadth amongst the many things that we have to do day in and day out. The way out is prioritisation.

It’s not about saying that something is not important. We know most things on your list are. It is about choosing what is critical at that moment, and doing other things later. Who knows, when the time comes, the next bit of task does not seem as critical as it seemed at that moment.

There are many tools and techniques you can use, and the internet is full of these techniques. The lesson is to start thinking about prioritisation, and start doing it, and you will eventually figure out what tools are the best for your needs.


New Year’s Resolutions

Note: This post is not related to programming.

Every year, many of us make a list of resolutions for the New Year. We follow them for a few days. Then one day, we have that one glass of beer, miss our exercise on one day, or eat that one chocolate, and then everything goes for a toss.

Why does this happen?

News Year’s resolutions can involve big lifestyle changes. Humans are creatures of habit, and changing so many habits at one go is not sustainable. A lot of these habits are built into our subconscious, and it requires conscious effort and focus to change each of them. Moreover, once we fail to follow one of the resolutions, we mentally toss the whole list out.

What can be done about it?

There is one way I’ve made some New Year resolutions work for me. I started thinking about habits and lifestyle changes well before the New Year’s Day. Then I gradually incorporate these changes into my life. Sometimes I go back to my old habits, and then have to start over again.This way, I have the time and the room for failure. If there’s a habit that I’ve not been able to adopt by New Year, I drop it from my list. Even with all of this, I end up ignoring most of my resolutions, but I’m okay with it. At-least this gives me a shot.

So here’s my advice. The right time to start following your resolutions is not January the 1st, it’s today.


Empathy Maps

I was introduced to the concept of Empathy Maps recently, and found it an effective way of translating a User Persona to a concrete problem statement.

Below is the version of Empathy Maps I was introduced to.  The purpose is to keep the user persona in mind, and empathise with their journey through a certain situation. That would help us translate their journey into a concrete set of problems to solve, and thus help us build the right thing in the right way. The map below helps us brainstorm what that persona would think and feel, what sensory inputs would they receive from their surroundings, and what action would they take. Then, we could think about their pain points during the journey, and how we can help them achieve any goals and gains they may be looking forward to.




I then tried using this version on a personal project, and struggled. Some categories overlapped, such as seeing and hearing. Other than that, I was not able to figure out how to make it goal oriented. For example, what does Say and Do mean? How does it translate into a problem statement?

As I read about Empathy Maps in more detail, I stumbled upon this link. This particular post helped me make the empathising activity more action oriented. Below is the image of the Empathy Map used in this post. Here’s a brief description of how this helped me –

Tasks describe the journey the user was trying to traverse, and the actions they were trying to take. Feelings and Influences described the internal and external motivations respectively that could affect their journey. Pain Points describe problem statements in terms of blockers and frustrations, and Overall Goals tell us the bigger picture of what they’re trying to achieve, and why are they executing a certain set of tasks.



Switching to the second version of Empathy Maps helped me focus my brainstorming activity to the current path the user was traversing. It also helped me focus at the bigger picture, and think beyond the software I already have in mind.

In conclusion, Empathy Maps are a means to an end. Use whatever feels more natural to you, and let me know about your experience!

Work Experiments

A few months ago, I was bored at work. The work was intense and challenging, but I had been on the same project for many years, and had was not doing anything new.

After a lot of thought, I decided to do something new.

The first thing I decided to get myself involved in was teaching. For an unsocial person, teaching is a very stressful job. At the same time, it is one of most rewarding jobs, as you’re directly having an impact on someone’s career. We started with conducting another Android Bootcamp, and then a workshop on Test Driven Development in Android, which was open to people outside ThoughtWorks. Most recently, I was a trainer in the Dev Bootcamp held for laterals joining ThoughtWorks.

The second thing I became interested is in the creation of a sporting league software system. See – USTA has these tennis leagues. Based on your rating, you can become part of a league, and play with tennis players of your ability. Based on your percentage of wins or losses, your rating goes up and down. It’s a well deviced system that keeps all level of players involved – from newbies to experts. I have been conducting experiments to figure out of something similar will work in India? Can a private party create the same ecosystem for other sports too?

I don’t what will happen to both of these career paths. I hope something good comes out of atleast one of them. Let’s wait and watch!

Getting Your Apps Ready for Android N – Background Optimization

This is the second post of a multi-part series on getting your applications ready for Android N. I will give an overview of one or more features in each post, and then list down the technical implications, and how you can get your apps ready for Android N. I will not go into syntax, or cover each option provided by Android, since they are already covered on the Android Developers Website. The focus will be on core changes that are likely to affect your application’s behaviour.

One major area where iPhone excels over Android is battery life. Even after the recent improvements,  there is no comparison between iPhone and Android battery lives. With Android N though, Android finally seems to have found the answer.

First, let’s think through what eats your battery life. When the phone is active, it’s the UI. However, when the phone is inactive, it still keeps draining battery life. The culprits here are implicit broadcasts registered through the Manifest. Imagine a scenario where the app goes from Wifi to Phone Data. The Connectivity Changed broadcast will be triggered. Scores of applications will wake up, see if they want to perform any downloads, realise that they don’t and then go back to sleep. Therefore, every time your phone goes through a variable network area (such as an airport), the battery just dies.

Goodbye Implicit Broadcast Receivers (Registered through the Manifest) –

With Android N, you’ll stop receiving the following three broadcasts if the receiver is registered through the Manifest – CONNECTIVITY_CHANGE, ACTION_NEW_PICTURE or ACTION_NEW_VIDEO. Neither can the app send the two latter broadcasts mentioned here.

Android is recommending that you get rid of statically-registered implicit broadcast receivers completely. They’re also recommending that you stop using unbound background services. They have an adb command that will make the app stop receiving Implicit Broadcasts that are registered statically, and also impose a timeout on Background Services when the app is in the background. The adb command given on their website did not work for me as it is. Looking at the source of AppOpsCommand, I realised we also need to specify the package. Therefore, command that you need to use is –

adb shell cmd appops set <APP PACKAGE> RUN_IN_BACKGROUND ignore

There’s a funny thing with this command though. It will start having affect only after you kill the app from the recent apps menu. Even if your application is not launched, you’ll have to launch it, kill it, and the option starts working.

What are the changes recommended?

The application will have to get rid of any dependencies on the three broadcasts that are being removed. I strongly recommend that any statically registered  implicit broadcast receivers are removed from the application. Android is still evaluating the option of removing the support altogether, but all indications are towards them removing it. Note that all broadcasts explicitly send to one application (such as GCM), will still continue to work.

What is the alternative?

Job Schedulers. Instead of receiving a broadcast on connectivity changed, the Job Scheduler will let you specify what you want to download, within what time frame, and on what sort of connectivity. With Android N, JobSchedulers also have the option on performing a Job on Content Provider changes. Therefore, you can now schedule a job to upload a photograph is there is a new photograph on the system.

What about unbound background services?

There is value in Android’s argument that we should stop using Unbound Background Services as much as possible, particularly if the application is in the background. If there is something that needs to go on, it should be a Foreground Service (such as a music player). The Background Service can anyways be stopped anytime when the system tries to free up resources. Therefore, if there’s something that’s done in the Background Service, it can very well be done in a global variable, which is itself liable to be cleared when the system tries to free up resources. I don’t know if and when Android will end up removing Unbound Background Services, but we should definitely start moving away from them.




Getting Your Apps Ready for Android N – Multi Window

This is the first post of a multi-part series on getting your applications ready for Android N. I will give an overview of one or more features in each post, and then list down the technical implications, and how you can get your apps ready for Android N. I will not go into syntax, or cover each option provided by Android, since they are already covered on the Android Developers Website. The focus will be on core changes that are likely to affect your application’s behaviour.

One of the coolest features coming with Android N is Multi-Window. By long pressing the recent apps button, you can activate the Multi-Window option, which will allow you to have two or more apps sharing the screen.

Screen Shot 2016-04-09 at 8.02.20 PM.png

What are the technical implications of this? Some salient features are listed below –

  • At any point of time, the system will still have only one resumed Activity. If there are two Activities side by side, the one that is not being used by the user will be paused.
  • It is possible for the Activity to be in landscape, while the system is in portrait.
  • If the Activity is locked in portrait or landscape, it will not go into Multi-Window, but rather fill the whole window. If the lock is applied through the Activity and not the Manifest, it will be ignored.
  • Activities of the same application can be launched adjacent to each other using FLAG_ACTIVITY_LAUNCH_ADJACENT.
  • The device might enable resizing of applications, or Picture in Picture mode.

What changes will you have to make to an existing codebase ?

  • The difference between onStart and onResume becomes important now. If you’re registering or deregistering receivers or doing any processing, that should now be done in onStart/onStop, and not onResume/onPause. For example, if you’re watching a video in parallel with WhatsApp, you wouldn’t want the video to stop when the user starts using WhatsApp. Therefore, you should stop the video in onStop, and not in onPause. On the other hand, if you’re playing a game with heavy action, you might want to pause it if the user uses WhatsApp.
  • Small screen sizes become important again. In the last few years, we had started ignoring UI glitches on smaller devices, since all new and important phones were at-least 4 inches in size.  With Multi-Window, supporting smaller screen sizes becomes important again, since your application might not have enough area available when multiple applications are sharing screen space. Android recommends starting from sw320dp, and scaling up from there.
  • As far as possible, applications should support both orientations. If an Activity is locked in a particular orientation, multi-window will be disabled for that Activity. Therefore, the user will end up going into single-window mode. This could be a jarring experience for the user, esp. if he gets used to multi-window.
  • An alternative (generally tap based) needs to be provided for any gesture driven action. For example, if you have an action that is based on a swipe left, on a multi-window app with resizing enabled, it will end up resizing the application instead of enabling that particular action.
  • There might be some changes in the technical paradigms we use to support tablets. Instead of having multiple Fragments, we might as well launch two Activities adjacent to each other. So far, Android is still recommending the use of Fragments. However, I am not convinced. Why introduce adjacent Activities if we’re to still use Fragments? Perhaps Android is setting the base for something it will launch in the future.

All in all, Multi-Window is an exciting paradigm shift in taking hand-held devices forward. The change is particularly useful in tablets, and in TV. Let’s wait and watch!

For more details, read the official Android guide here