General, Technology

User Experience and the Locality Principle

Designing a great user experience (UX) for complex business software is non-trivial to say the least.

Screens with complex functionality along with large amounts of data in such systems do not make things easier.

One of the key elements of good UX is making it easy for the end-user to find “things” in the system that is relevant to her.

This is where I think the Locality Principle comes into play.¬† It’s a well known principle in computer science and has implications in memory access optimization.

So what does this principle tell us? To keep things super simple have a look at this video which explains the gist of the principle.

Now how do we apply this concept when designing user experience (UX) in business software?

End-users of a business software system would typically work with (or “reuse”) a relatively small set of data (and screens) during a given time period. (e.g. during a business week). Therefore the information they search for and work with during this period should be fairly predictable.

If we can build some “intelligence” (short of AI ūüôā ) into these systems to identify¬† information access patterns of users in the system, we could use that “intelligence” to suggest the next possible interaction on the current UI for a given user. This would alleviate the need for the user to “find” the next screen to work with in the system and make it easy to “jump” between screens.

It must be noted this is more richer than “Recent Screens” functionality, which merely puts the last used screens of one user in a stack. Think something like Amazon Recommendations instead.

So the idea is simple, we should leverage the principle of locality in UX design to figure out the next information requirement (e.g. next screen) based on users previous UI interaction patterns


Management, Strategy

How do large organizations solve the Innovator’s Dilemma?

Large companies have a problem. Even when they are aware of early disruption in their target markets they can’t help but to continue improving existing products and carry on extracting higher profits. Organizational structures and processes of these big players are geared purely for optimizing the status quo.¬†¬†

In the meantime the more nimble startups keep on experimenting and innovating in tiny segments of the market that are not relevant to the big players. They can do so due to the flexibility (or lack) of process and organizational structures. They also don’t have the burden of satisfying¬†all customers all the time.

For the bigger firms allocating management focus and resources to try out disruptive innovations does not make economic sense.  But does that mean large players should totally forget about disruption? Probably not. One possible approach would be to become early investors in potential disruptors with perhaps plans for more involved future partnerships or even a merger/acquisition.

In such a scenario the larger firm should ensure that the smaller firm (startup) can operate independently with it’s innovation game and failure is not frowned upon.

The big players should look at such investments/acquisitions as playgrounds to test hypotheses, fuel innovation and come up with products that would disrupt the current market.

Now the challenge for the large firms would be in identifying potential disruptors early on and thereafter making sure they do not stall the innovation of the startup.

On the other hand the key for the startup would be to make sure that the larger firm’s intentions are good and has no ulterior motive of killing the disruption!

Management, Strategy, Technology

What’s the Chorus of your Product?

After listening to a song you like what part of the song plays over and over in your head?

What part of the song do you keep on singing in the car to work or in the shower?

What part of the song do you hum to your friends when telling them how great it is?

It’s the Chorus!

The chorus of a song gives it a unique identity. It is the most important ‘feature’ that makes it different from other songs. It’s USP.

So what can the software industry learn from the music industry?

Let’s first have a look at this fascinating video (starts at 0:15) of how Sia comes up with a new song. (in fact it is the inspiration behind this blog post)

The cool thing to note here is how she mainly focuses on identifying the chorus and getting it to sound awesome, even without any lyrics.

So if you are building a consumer (or even enterprise) software product make sure you identify it’s Chorus,¬†the feature that makes it unique. Then focus most of your effort and resources on it to make your users fall in love with it and talk about it with other potential users.

It’s amazing how we can stimulate product strategy in our own industry by looking at other almost unrelated industries. The key is not to isolate your knowledge to within your industry alone but widen it to other industries and try to draw parallels that will help with your own strategy.


Strategy, Technology

‘Time to Value’ should be the new ‘Time to Market’


It’s fascinating¬†how the software industry¬†has built and leveraged technologies that could¬†deliver software products of good¬†quality at amazing speed.

The key technologies (in my opinion) that enables such speed are:

Cloud – Fast and Reliable distribution channel for software.

Microservices¬†– Smaller units of software that can be developed and deployed independently and ‘quickly’ ¬†by two-pizza teams

Containers (e.g. Docker) РMaking sure that the software (primarily microservices) have a reliable and consistent environment to execute.

Software vendors should now focus on how fast their customers can start extracting actual value from software instead of how fast they can get their software products to market.

Time to Value should be the new Time to Market!

Management, Strategy, Technology

The biggest challenge for “traditional” software vendors moving to a SaaS model is not technical

Image Credit:

Cloud Computing is probably¬†the longest surviving¬†buzzword in the IT industry for¬†the past¬†decade or more. From a software buyer’s point of view the important decision of¬†going for a “Cloud Solution” ¬†is based on economics, more specifically the¬†CapEx vs. OpEx trade-off. The pay-as-you-go nature of cloud computing is perhaps¬†the most important economic¬†feature¬†for customers.

Cloud computing has¬†three well known service models¬† IaaS, Paas and SaaS. Out of these, Software as-a Service (SaaS) is perhaps the most convenient model of acquiring IT for operating a business. ¬†The huge success of enterprise SaaS vendors such as¬†Salesforce¬†and more recently Workday¬†is evidence¬†that¬†many enterprise customers¬†are moving towards SaaS for software “procurement”.

These new kids on the block have prompted the “brick and mortar”¬†software vendors that follow the old model¬†of building software, burning it on a CD and shipping it to their customers for on-premise installation¬†to follow suit. These vendors are now¬†making their software more architecturally and technically cloud friendly. What¬†this usually means is that the software is now runnable on cloud infrastructure (IaaS) like Amazon AWS or Microsoft Azure.

Now building software that is more cloud friendly is one thing, but actually moving towards a true pay-as-you-go SaaS delivery model is a whole new ballgame for the traditional vendors.

I think the biggest challenge for existing non-SaaS vendors is not technical but its rather about overhauling their business/financial model. When moving to SaaS, the customers who used to pay all the license fees upfront will now be using a subscription payment model. This means the financials (such as cash flow) of the company need to be looked at from a different angle. It may also affect how sales and marketing approach their roles since customer LTV (Life Time Value) is now a bigger concern.

Possible ways to overcome this challenge would be to partner with (or even merge/acquire) another cloud company and piggyback on their business model for SaaS delivery. But when choosing a cloud partner it would probably be a good thing to avoid another SaaS provider and instead select an IaaS or PaaS provider to avoid market share erosion due to conflicting products.

Another way to address this challenge would be to setup a separate business unit for the cloud SaaS business. This would enable all new customers to be directly part of the SaaS business unit while existing customers are gradually migrated.


Docker compose does not inject host environment variables in MacOS

When using docker-compose to orchestrate your container services it’s common practice¬†to pass environment variables set in the host machine through to your containers. This is especially useful when you want to configure¬†passwords/secrets for¬†your applications running inside the container. By doing this you can avoid including such sensitive¬†information in your docker-compose.yml file.

Let’s consider the following extract of a docker-compose.yml file which defines¬†two environment variables required for a MySQL container service named ‘db’. ¬†The highlighted lines shows how the variables are not given any values. This essentially tells¬†docker-compose to¬†inject the values using¬†the corresponding environment variables in¬†the host machine.

version: "2.0"

   image: mysql:5.6.26
     - '3306:3306'

Now usually¬†what you would do in Linux or MacOS is¬†use the “export” shell command to set values on the host machine before calling docker-compose up¬†to bring up the containers.

export MYSQL_ROOT_PASSWORD=password
export MYSQL_DATABASE=moviedb
docker-compose up

This works on Linux, in my case an Ubuntu 16.04 droplet on DigitalOcean without any issue. But it¬†doesn’t seem to work on my dev machine running MacOS (Sierra) with¬†the latest version of Docker¬†17.03.1-ce¬†(at the time of writing)

Strangely when running docker-compose up on MacOS the MySQL container complains that the MYSQL_ROOT_PASSWORD environment variable is not set. Further inspection revealed that both variables were empty in the container.

So it seems like the “export” shell command does not work with compose on MacOS.

The trick to solving this problem in MacOS is to instead use a one liner in the shell like so:

MYSQL_ROOT_PASSWORD=password docker-compose up

Note: I have removed the MYSQL_DATABASE=moviedb segment from the above command for brevity.


Key Learning from the GitLab Incident

GitLab is an awesome product!¬†Although I don’t use their¬†hosted service at, I’ve been a very happy user of the¬†product in¬†an internally hosted setup.

They had a pretty bad (and well publicized) incident a couple of days back which started with spammers hammering their Postgres DBs and unfortunately ending up with a sysadmin accidentally removing almost 300GB of production data.

I can empathize (#HugOps) with the engineers who were working tirelessly to rectify the situation. Shit can hit the fan anytime you have a production system with so many users open to the wild internet. The transparency shown by the GitLab team to keep their users informed during the incident was awesome and required amazing guts!

Now most blogs/experts talk about the technical aspects of the unfortunate incident. These mainly focus on DB backup, replication and restoration processes, which are no doubt, highly valid points.

I’d like to suggest another key¬†aspect that came to my mind when going through the incident report, the human aspect!

This aspect seems to be ignored by many. From all accounts it looks like the team member working on the database issue was alone, tired and frustrated. The data removal disaster may have been averted if, not one but two engineers were working on the problem together. Think pair-programming. Obviously, screen sharing can be used if the engineers are not co-located.

I know this still does not guarantee a serious f*ck up, but as a company/startup you would probably have better odds on your side.

An engineer should never work alone when fixing a highly critical production issue.

Image Courtesy: Flickr (licensed under Creative Commons)

When trying to fix critical production issues in software systems its super important to have a aircraft style co-pilot working with you on the look out for potential howlers that can occur, e.g. rm -rfing the wrong folder.

There is always something to learn from adversity, Rock-on GitLab! Still a big fan.