Skip to content

There is no such thing as risk due to “the cloud”

Problems with Amazon’s cloud computing service over the weekend underscored how businesses and consumers are increasingly exposed to unforeseen risks as they embrace life in the cloud, Quentin Hardy reports in Monday’s New York Times.

The risk

The risk to consumers isn’t that the Cloud exposes them to additional risk that they wouldn’t ordinarily be exposed to, the risk is that businesses have disaster recovery policies that are either unworkable, too long in duration or otherwise flawed.

Boards are specifying that disaster recovery be part of companies’ plans but without adequately addressing the risk of failure due to a datacenter outage against today’s demands of “dial-tone” quality service. Technical leaders, in turn, take the short-view assuming that it performing an actual recovery could never happen, or it would be such a lightning-strike event that people will understand when it happens.

They probably won’t.

In today’s fully-connected world, you need to be fully-connectable with almost no exceptions to be perceived as professional and worthy of a consumer’s business.

“The Cloud” isn’t what you’re actually worried about

Customers aren’t exposed to some new cloud-based risk that didn’t exist previously, they’re exposed to the same old risks that concentrations of compute power have had since the first computers were built and installed. The difference is that today, customers rely on those services in a very personal way.

Every big ecommerce system has had this risk since their inception. Fires burn. The power goes out. Tornados hit buildings. Earthquakes break infrastructure. Server racks get unplugged to plug in the vacuum. Your systems simply need to be ready for this eventuality.

Companies with any kind of expectation of service need to be ready for this to happen and completely focused on continually reducing downtime until its systems are fully resilient to regional datacenter crises.

The cloud actually helps businesses solve these problems by providing similar services in multiple locations. Amazon has several datacenters, and businesses could easily be taking advantage of those services to yield increased reliability.

The challenge

From the moment you have core customers that you can’t fail, you need to have a plan that executes in minutes, seconds or microseconds. If you’re planning on hours, you’re losing customers, unless your competitors are in the same datacenter you are and have the same kind of recovery plans. You’re not really trading cost against risk. You’re trading cost against customers. You are trading your, hopefully, good reputation.

It isn’t hard if you proceed in a stepwise manner, reducing the downtime and solving problems until you get to the core issues that exist in dealing with transactions across multiple datacenters. These problems are solvable, and the expectation for recovery speed should be constantly rising.

But what about the cloud?

Building on the cloud is likely to have a advantage versus doing it the old way with your servers in your datacenters. I would be very surprised if Amazon doesn’t provide a new level of service which allows for nearly seamless recovery in such failure situations in the next year or two. Amazon has the datacenters, bandwidth and infrastructure to make this happen. The cloud is likely on the cusp of reducing this kind of risk.

Even if Amazon doesn’t “fix” this problem with no work on your part, they still offer services across multiple regions and make it easy for you to fix your own problem, as they suggest in their whitepaper.

The real problem

The problem for consumers is that they don’t understand how seriously companies take their responsibility to build robust systems. I’m not sure what an adequate measure of that seriousness would be, but customers know the impacts when they see them.

As a business, your problem is getting the leaders of your company to take these risks seriously and plan for infrastructure failure as if it is an eventuality. Stop wasting time rehearsing for recovery and build robustness that works so you don’t have to rehearse. Maybe even “hire” a chaos monkey and make sure it knows how to really break your systems.

Posted in Thoughts.

Thanks, LinkedIn, I feel better now

I feel much better about LinkedIn’s security now…

It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.

Indeed it is worth noting that LinkedIn just started using password hashes and salt “recently.” What obvious aspects of my security will they be protecting in the future?

Maybe TLS on service calls?

Posted in Thoughts.

Tagged with , , .

Please join me at the virtual Thanksgiving table

Credit: Flickr user brad_holtYou know what I’m thankful for this year? You. It might sound cheesy, but you’re my friend or maybe you’re my family, or maybe you’re someone I’ve never met. I’m not sure, because I don’t know who is reading this right now. If I know you or not, I’d like to invite you to join me at the virtual Thanksgiving table this year.

Here’s what you do. There’s a website that will let us all share a stream of pictures from our Thanksgiving. Your assignment, if you choose to accept it is to take a picture or two or ten of your Thanksgiving – maybe friends and family, the meal, something you’re thankful for.

Whatever that is, take a picture of it. Sign up for Shutterous on the website and click this link so you can join and upload pictures. If you have an iPhone or iPod Touch, grab the Shutterous app in the App Store. You can sign up for Shutterous and find the public event right in the app.

It will be great if you all come to my virtual Thanksgiving.

I promise you won’t get stuck at the kids table.


Posted in Uncategorized.

Delivering projects on time with LiquidPlanner? There’s an app for that.

Humble BeginningsWith the possible exception of the equator, everything begins somewhere. – Peter Robert Fleming

The Beginning

It was the beginning of the summer and I was sitting with Charles Seybold and Jason Carlson of LiquidPlanner to discuss the possibility of building a mobile application to support their SaaS project management system. It was fun to be working with Charles and Jason again — we’d worked together at Expedia while they were incubating the ideas that would lead them to leave Expedia and create LiquidPlanner.

From the beginning, the passion for the product and the details came through and we quickly sketched out and talked through an initial design for the application and the API (currently in beta) that would sit behind it to provide access to LiquidPlanner.  The team had a solid vision for what they wanted the app to do both in the initial incarnation as well as over time. Following the principles that launched LiquidPlanner, we focused on the functionality to deliver in version 1.0.

I headed back to the luxurious offices of Deep Focus Technologies, to work on turning the white board sketch into an initial set of wireframes so we had something more concrete to visualize.  More discussion, refinement, and a schedule in LiquidPlanner and we were ready…


The project got the green light and I began work in earnest.  Back at LiquidPlanner, Brett had a super-early release of the API — we were almost ready to begin hooking things up.

The Technology

LiquidPlanner’s REST API is as easy to use as any REST API, but developing the app was made easier by a few of pieces of software upon which I relied heavily.

The first was my data framework.  For most of the summer I had been developing an application using sqlite3 on the iPhone that supported CRUD within the standard UI framework.  The application hasn’t been released yet, but the framework that sits under it keeps finding its way into released code.

The intention of the framework was to support a variety of data providers, all rendering and providing update facilities through a common set of code.  The first test: was the framework able to support a REST API instead of sqlite?

My display framework combined with Justin Palmer’s httpriot, had me up and talking to the LiquidPlanner APIs in less than a day.  Basic functionality quickly took shape, and over next several weeks the application became began to resemble the things we had planned to build.

Also extremely useful for developing this type of application was the combination of Todd Ditchendorf’s HTTP Client, Tuffcode’s HTTPScoop and some Apache request forwarding trickery.  This setup was my x-ray vision, allowing me to manually play with requests, as well as inspect the traffic to and from the iPhone emulator as it ran my code.  This visibility was invaluable as it could easily expose problems in the application’s messaging.

Working With the Team

LiquidPlanner has retained some of the habits that initially made our former employer what it was — rapid execution, focus and eating your own dogfood. This time, the dogfood was both the application and the API supporting it.  There are always challenges when working toward a moving target.  We used LiquidPlanner’s built-in chat feature and tasks to communicate changes, drops and track work items including a specific set of work items, rumored to exist, apparently called defects.

I enjoy opportunities to work with small, focused teams. There’s an experience of progress that doesn’t exist everywhere.  It seems that people who live in that world every day might sometimes forget what the rest of the world is like, but I doubt they’d want it any other way. Everyone focuses on the goal and there is little to get in the way of progress.

As the work progressed, I would spend a couple of days in LiquidPlanner’s offices, focusing closely on user feedback and interactive design/development sessions.  The rest of the week I was meeting with other clients or working at my home office.  Either way, the schedule required to run my business and make the expected amount of progress on the project required occasionally being out-of-sync with LiquidPlanner’s office hours. I relied on the information in the LiquidPlanner system to maintain connections between where I was and where others on the project were going.

As the milestones passed, the application became increasingly more functional.  The work and tracking I once did on the web app was soon working on the iPhone.


The software development process at LiquidPlanner revolves around the product; it is the product. Team uses the system to store documentation, for tracking defects and to constantly chatter about what is happening. They use it for tracking releases and making scope decisions as the work moves beyond the time allotted for the current sprint. The system has become the center of their process, and the iPhone app was designed to become a growing part of that evolving system.

The tool supported functionality throughout the business. Chatter between PR, sales and marketing communicated status on projects in progress.  Creative brainstorming and tasks for upcoming blog posts had their own places and schedules.  Work in progress and work waiting for a future start was all there.  If there’s work to be done, it finds its way through the system.

The Release

We developed and tested the app until we had the initial product goals finished and submitted it to the app store in October.

The only thing more rewarding than watching something grow from some scribbles on a whiteboard to a released product in a short period of time, is knowing that customers are using that software to make their projects easier to manage and to help their people be more productive.

If you’re curious about the system, LiquidPlanner offers a free trial.  You can hook your iPhone up to LiquidPlanner for free as well. When do you have to pay? Practically speaking, if LiquidPlanner helps you execute on your project plans efficiently, you only pay if you don’t use the product.

Posted in Products.

First Glimpse: Audiotron controller for iPhone/iPod Touch

A first peek at an upcoming iPhone/iPod Touch Audiotron controller program…  More to come.

IMG_0347 IMG_0346

Posted in Uncategorized.

How To Fail at Mobile

Mobile software development takes persistence and patience and an innovative spirit to succeed.  The number one recipe for success is release, understand feedback and observed measurements and iterate.  Some companies seem far better suited to this model than others ones, but clear expectations, vision and persistence can bring success to a variety of mobile strategies in a variety of organizations.

There are many ways to fail.  Here are some you can avoid with understanding, planning and expectation setting.

Which way?

Don’t Measure

If you expect to learn anything from your efforts, take the time to build in the hooks to appropriately measure your application.  Understand what people do, who those people are and how they relate to your mainline business.

If you propose to support transactions on your mobile platform, who are those custotmers?  Is a positive, but less than online conversion rate for customers good?  Some in your organization will slap one another on the back and assume that you’ve succeeded if you convert some, but less customers on your mobile platform.  Did you succeed?  Unless you understand your customers and your app’s usage, your results are inconclusive.  Be honest about the data and seek deep understanding.  If you don’t have the time to measure, you probably don’t have the time to succeed.

  • Are the mobile conversions incremental to your business?
  • Are the customers that “should” be converting in the mobile client, but not converting going elsewhere or to your “main” system?
  • If your mobile app targets a more immediate need, i.e. people need your product immediately because they are mobile, is accepting a lesser conversion rate for mobile transactions acceptable?

Get Caught in the Religious War

HTML5?  Native Apps?  Hybrids? determine a strategy and go.  If you believe mobile is valuable to your business, try to create that value.  Measure your response and continue to work on your pitch.  Technology rarely stands still.  If you’re waiting for your internal technology to be “ready” or waiting for some magical universal technology to make everything easy, universal, better or whatever there will be another glittering technology on the horizon.

Let App Store Comments Determine Your Fate

The app store comments will provide good feedback and terrible feedback all wrapped in one neat little package.  Don’t dismiss it and don’t take it too seriously, but struggle to understand the message.  In every one-star slam, there may be the kernel of improvement.  Understand what your customers want, rather than what they’re complaining about.  If your users seem off the mark, how can you educate them or get the app in the hands of the people it is targeted toward?  Bad comments may simply be the result of mismatched experiences and expectations.  Align the users and the application and perception will improve without writing another line of code.

Don’t Promote

Promote your application to the people you targeted it towards.  If you’re building a brand extension app for a specific purpose and have a channel to promote it to the people who will likely find it useful, use that channel.  You can stack the deck in your favor in terms of app store perception.  Research has shown that the expectation of a bad experience creates a bad experience, and conversely, the expectation of a good experience creates a better experience.  Get your app into the hands of the people who will have the best experience with it tell them what to expect and how the app will help them.

Don’t Iterate

If you don’t have resources to continue to make progress on the application, maybe you shouldn’t have started.  No application hits the market perfectly, and software never gets better without intentional effort, feedback and iteration.  If the comments show that you’re on to something for some set of people, figure that out and make it better.  If you miss the mark for others, understand them and set a course for the next release.

Don’t Innovate

Your business may be cut-and-dried, but the effect of mobile may reach beyond transactional power.  Brand loyalty and customer acquisition costs are high in many industries.  Assigning correct value to creating improved customer experiences, reduced customer service cost and a feeling of consistent customer support may help you better understand your mobile strategy.  Looking at your app as a marketing tool and a brand extension tool rather than an engine of direct transactions could be helpful.  On the other hand, maybe you are about driving transactions at this moment at the customer location.

There is no question that mobile is a bit different animal than your current business.  You have an opportunity to be a leader and ride the mobile buzz.  Contact me for more information on I can help your mobile strategy succeed.  You can reach me at matt at

Posted in Thoughts.

Tagged with , , .

Expedia application live in the app store

Deep Focus Technologies’ latest development efforts have been released in the app store.  The Expedia Itinerary Viewer application provides access to itineraries while you are traveling.

Download the Expedia Itinerary Viewer application
Customer comments on this application’s development
trip-list trip-home air hotel
Find iPhone apps at AppStoreHQ

Posted in News, Products.

Just Released – Theater Tool 1.0 for iPhone

icon21Now, you can use your iPhone to help you adjust your home theater.  Theater Tool offers audio analysis tools to support balancing speaker levels and a delay calculator to assist in setting the appropriate delay between front and rear speakers.

More information on the product page.

Get Theater Tool on iTunes.

Posted in Products.

Making a couple of great products work together

Update: updated package, md5 and install path the readme and this post.  Correct install path is ~/Library/Scripts/Applications/Camino.  Thanks David for the correction and including the script on Pimp My Camino.


Even with the recent release of Safari 4 beta, I’m hooked on Camino as my browser.  It is quick and lightweight.

I’ve also recently started to use Evernote, both on my Mac as well as my iPhone.  These are great products, but the only way to enable web clippings from Camino to Evernote in the browser is by going through a bookmark that contains a javascript URL that does the clipping.

Jealous of the Firefox community and their plugin, I wanted an Evernote button on my toolbar to do the clipping, so I built a simple applescript to accomplish the task.  If you’d like to try it out, you can download it here. (md5sum:f7738b0ec8716c2b6979f68edc98e910)

Install by unzipping the package and drop it in your ~/Library/Scripts/Applications/Camino directory (~ is a shortcut for /users/username).

Next, customize your Camino toolbar.  You’ll see Script:Evernote in the toolbox.  Drag it up to your toolbar and you’re good to go.

Because the script communicates with Evernote via applescript, you’ll need to have Evernote on the local machine.  If you’re reading this far, you probably already do.

Happy clipping!

Posted in Uncategorized.

pinch media presentation on iPhone AppStore analytics

Required viewing if you’re considering an iPhone application.
View more presentations from pinchmedia. (tags: pinch media)

Posted in Uncategorized.