Monthly Archives: December 2014

Clueless in Seattle – How Amazon Doesn’t Get Mobile

Have you bought a book from Amazon on your phone? Unless you’re uncommonly persistent, you haven’t. The reason is that Amazon is clueless about the mobile use case.

This is how it works:

  1. You hear about a book in some way (social media, email etc)
  2. You open your Kindle app, but you can’t buy books there
  3. If you really want the book, you download and install the Amazon app in the hope that you can buy the book there. No luck, you can’t buy e-Books through their app (!)
  4. If you really, really want the book, you open your browser and navigate to the Amazon website. Which promptly tries to redirect you back to the app (where you can’t buy books, remember?)

Buying an e-Book is the obvious mobile use case: Happens on the go, should take less than two minutes. But Amazon is so blinded by their previous successes that they believe their website and their proprietary devices is enough. It isn’t.

Some organizations do need a mobile app.

Why You Don’t Need a Mobile App

I’ve been discussing mobile apps with several customers lately, and they all seem to think they need a mobile app.

The fact is: Most organizations do not need a mobile app.

Your users might need some functionality available on a tablet computer, but that can be handled with a modern web application. It does not require you to increase the complexity of your technical infrastructure with apps written in new programming languages and managed through other tools.

The only time you really need an app is when your users have many, short interactions (less than two minutes), and these have to happen in a situation where you cannot use a tablet. Are you really in that situation? If not, save your energy for something more useful than building mobile apps.

Do You Know It All?

Last week’s Technology That Fits newsletter (sign up here) stimulated some interesting discussions. I showed the following graphic:

Doomed Projects

Everybody agreed that projects that choose good tools for good reasons are good, and projects that choose bad tools for bad reasons are bad. But some disagreed on Learning and Lucky categories above.

I call projects that choose good tools for bad reasons “lucky”. They are CMMI level 1 – sometimes they succeed, sometimes they fail, and they never get any wiser. I’m not recommending you accept that as a satisfactory state of affairs, but for an individual project, being lucky is enough to pull off a success.

Projects that seem to have good process but make tool choices you disagree on are “Learning” projects. Some people will walk out or loudly complain if their favorite tool is not used. I find that to be a narrow-minded approach. If clever people have chosen a different approach from you, it means you have an opportunity to learn. Don’t think only you have all the answers.

Put Your Parents in the Cloud

If you’re going home for Christmas, you will probably be asked to have a look at your parents’ computer. If they are not already set up for cloud services, make sure you spend a few hours getting all their stuff into the cloud.

For organizations, there are many interesting and relevant discussions to have before deciding whether a cloud-based solution is right for you. But for private consumers, it is a no-brainer that all their data should reside safely in the cloud.

Several people I know in my parents’ generation have had their laptops stolen or lost them due to fire, flood or other calamities. Most of these were not set up for cloud services, which meant that irreplaceable vacation photos as well as important documents and emails were lost.

I’ve set up my parents with

  • IMAP mail with their ISP (they used to run POP3 which placed all mail locally on the machine)
  • Microsoft OneDrive for documents and photos (they run Windows and the generous 15GB limit means that a free account is enough)
  • Google Play (for their music, which did not fit under the 15GB but easily comes under the 20,000 song limit for free Google Play account)
  • Norton 360 for antivirus etc

Make sure you give the gift of Cloud safety this year 🙂

You’re Not Here to Write Code

Too many programmers think that their job is to write code. It isn’t.

The job of the programmer is to help the business solve a problem using appropriate technology for the task at hand. The programmer knows (or should know) the available tools and will hopefully select the right one for the task.

Unfortunately, too many programmers suffer from framework-phobia and don’t trust any code they have not written themselves. That takes more time, causes more bugs and will be harder to maintain down the line. Use good frameworks and solve problems!

use_the_framework

Useful vs Useless Meetings

As I wrote about in my last post, some meetings are incredibly useful and productive. But, as the Wall Street Journal just pointed out, many meetings are a complete waste of time.

Meeting Contribution

The difference lies in whether the meeting has a clear purpose that is articulated in advance. By making the purpose clear up front, you can also make an informed decision about which people are likely to be able to contribute meaningfully, and which people will just be eating donuts and checking Facebook. Don’t invite the latter group.

The above graph is from this week’s issue of the Technology That Fits newsletter, where I discuss the issue further. Sign up here.

Don’t Try to Solve it Alone

One of the members of the Danish Oracle User Group was facing a difficult technical challenge. They wanted to tap into the collective wisdom of the user group, so we set up what we call a mastermind meeting. Lured by an interesting challenge (and the offer of beer and food afterwards), a number of experienced developers showed up. The problem was presented, and the group suggested and discussed solutions. It was magical to watch how each idea triggered the next, until we had come up with an excellent solution we were confident would work, as well as a workable fallback solution.

If you are faced with an important decision in your IT architecture, do not try to find the solution on your own. Even the best and most experienced IT architects do not posses a magical quality that allows them to always deduce the ideal answer. The quality of your decision grows exponentially with the number of knowledgeable people you involve. Gather a small group and discuss your challenge – you will find that the group together will come up with a much better solution than any one member could.