TITM Interview on Mobile and the Cloud

I'll be speaking at http://www.techinthemiddle.com on September 11th. Highlights from my interview with the conference coordinators appear below. I hope to see you all there!

August 30, 2010: Take 4: Q&A with J Schwan - J Shares His Take on the Future of Mobile and Cloud Computing.

J Schwan is the Mobile Technology Practice Partner at Solstice Consulting, one of Consulting Magazine's 2010 Seven Small Jewels.

TiTM: Why did you choose to focus on technology/software for your career choice? Was there a defining moment when you just knew that this is what you wanted to do?

J Schwan: I went to college in the late 90s and the advent of the web. The aspect of connecting people and opening lines of communication that didn't exist before really interested me. I've spent my career exploring those capabilities and building systems that I feel genuinely have made people's lives easier. Whether it's a business or a personal system, it's a great feeling to build a tool that helps improve someone's day.

TiTM: What are some trends you are seeing right now and where do you see the mobile and/or cloud spaces evolving within the next year?

J Schwan: For the cloud I think the services will start converging. As more mission critical information begins to be stored in the cloud, individuals and companies are going to be more concerned about the viability of the service provider. Similar to other utilities, I think we'll end up with a couple large players, with some level of government regulation. This may not be in the next year, but it's where it's headed.

For mobile I think the technologies will continue diverging in the near future. We're just on the brink of understanding the capabilities of these devices, and I'm not sure the OS battle has even started yet. Just look at Android's market share in under 2 years! As the mobile technologies continue to diverge, companies need to be smart about where they make their mobile investments.

TiTM: What would you say is the current state of the Chicago tech community?

J Schwan: It's OK. I think we have a lot of knowledge and passion coming out of our university system but I think the investor community is weak. Luckily with the introduction of mobile and cloud technologies, the necessity for tech startups to require large up front capital is decreasing.

TiTM: Tell the Tech in the Middle Audience something interesting about yourself that isn't included in your biography.

J Schwan: First programming experience came at the age of 8 building a game (shark chasing a turtle) built in Basic on the Commodore 64.

High Performance Mobile Apps - "It's all TCP/IP, Brother"

I started my career at a Big 4 consulting firm in the mid-90s. First year analysts at the firm were referred to as “green beans” and boy was I green. Educated as a Materials Science Engineer and without any real programming education in college, I had a lot to learn and I had to learn it fast. I was also lucky enough to be part of an emerging technology group called the Internet Center of Excellence or "ICE".

With the retail adoption of the Internet, companies were investing heavily to get their first generation websites off the ground. At the same time, internet technologies were changing rapidly with very little standardization; which equated to our group working our butts off trying to get dot-com and brick-n-mortar sites launched on rickety app servers, poorly performing databases, 10 MB networks and limited, expensive, hardware.

Needless to say, our biggest problems were usually around performance. Each and every problem was unique, sometimes having to do with the App Server waiting for a database call, a Web Server waiting for an App Server to finish processing or a web browser waiting for some HTML to be downloaded. There was never a silver bullet to these problems, but as a trained engineer, I had a pretty good knack for using the scientific method to isolate variables and determine what the route causes were, so I got assigned a lot of the performance problems to debug.

I was an applications guy and I would work with the guys on the infrastructure side to figure stuff out. One day I was racking my brain on a particularly tough performance problem. We were working on a large greeting card company’s e-Commerce site and the ‘Checkout’ function was taking forever. The lead infrastructure engineer on our team was a guy by the name of Garren Du. Garren was a cocky, but likeable, New Yorker who was very smart and swore a lot. He always seemed to have a can of soda in his hand and wore a sly smile on his face when he talked, often making brash statements, hoping to strike up a good-natured argument. Garren was one of the more senior guys on the project (and when I say senior, I mean like, 25). Being a 22-year old green bean I looked up to him and thought him wise beyond his years. Turns out, he actually was.

Struggling with a particularly tough issue, trying to figure yet ANOTHER application server, I asked Garren, “How do you keep up with the Internet technology changing so fast? It makes it so hard to pinpoint problems. Every project is a different database, a different app server a different web server. It’s impossible to know it all!”

His response was simple, “It’s all TCP/IP, brother.”

I wasn’t shy about my greenness in those days, “What’s TCP/IP”?

“It’s a standard networking protocol, it’s the way all this data is packaged up and sent flying around the network and the Internet. I don’t care what the server is, call it what you want, Informix, Blue Martini, BroadVision. It’s all the same sh*t. It’s just TCP/IP man. I can write a shell script in Unix, pop open a TCP/IP socket connection and do the same thing that any of those overpriced software packages claim to do.”

“Yeah, but how’s that going to help me fix these performance problems?” I asked.

“Because it’s simple man. SMALL DATA. Small data means fast performance. You keep your data small, your application is going to be quick. You got big data, you got big problems.”

“OK well how do I keep data small?”

“Small and infrequent queries to your database. Getting only what you need. Small content output from your app server so it doesn’t take forever to get to the web server. Small images on your webserver and small includes on your web pages, so it doesn’t take forever to download stuff. And here’s the other thing. Keep the data close to your end users. The further away data is, the longer it’s going to take to get it to them. It’s simple physics man. If the data is on the web server, it'll be fast; if it has to go to the app server, slower; back to the DB, slower; to some other external systems, SLOWER. So you've GOT to cache that sh*t, on every tier. Limit that TCP/IP traffic. . .But not too much or you’ll f*ck up your memory.”

Garren was smiling, while my head was spinning, Garren said, “You can comb through that code for hours looking for the needle that’s causing those problems. Me, I packet sniff the network stream and I can tell you exactly why something is slow. It’s big data man.” He smiled, knowingly. “Now come on let’s go get a coke.”

Garren's simplistic view of the Internet holds all the more true for mobile applications today. Now more than ever, we’re dealing with limited hardware (cell phones), limited network speed (cell networks) and rickety new technology (iOS, Android, etc.). So how do we deal with it? Keep it small, brother. There's a million manifestations or practical tips on this, here are a few of my favorites:

• Limit the download footprint of your mobile web pages/services by minifying the whitespace in your code. Don't include content that is not going to be displayed or used. This includes heavyweight javascript libraries or irrelevant CSS files.
• Limit your use of cookies. Cookies get transferred with every request/response. That's extra data being transported over TCP/IP that probably isn't being used.
• Avoid redirects in your codebase. Redirects cause additional TCP/IP roundtrips between the client and the server. They're brutal over slow connections.
• Batch your data requests. Limit the amount of times you need to go back to the database for any given page or service. This can apply to the front end as well by using CSS sprites instead of having individual images downloaded. That's less data being downloaded in fewer TCP/IP trips.
• Cache cache cache. Use Cache Control headers on your services to your advantage, and use the power of the internet to cache relevant parts of your app. If you want more details, read this. And cache on other tiers as well. Use HTML5 DOM Storage to cache information locally in the browser. Pre-generate dynamic content asynchronously and store it on your web server instead of having your app server generate it on-demand everytime. Store common database queries in your app server's application scope, and share it amongst users. Limit that TCP/IP traffic!

Regardless if you're building mobile apps, or web apps, or client server or Minority Report apps, this premise will always hold true. Keep it small. It's all TCP/IP Brother. Big Data means Big Problems.

Let's help each other out and put some other performance tips and tricks in the comments below, eh?

Happy coding,

-J

Mobile Apps: Make Your Users More Awesome

So out of the 239,000+ apps in the App Store (and 48,000+ publishers), active iPhone users download roughly 10 apps/month and launch an app fewer than 20 times before discarding it. What's going to make yours stick? How are you going to make your icon worth clicking on after you've gotten them to download it? The answer: Make your users more awesome (or at least more interesting). Give them a reason to mention your app when they are asked "What new apps you got?" To do this, understand that mobile users are looking for apps that provide one of three things:

1) A utility to get things done (quickly)

2) An answer to a question in a local context

3) Something to entertain their ego while they are waiting for something else

Your app should fit into one of these three scenarios. If it doesn't, it's probably not going to make the 20+ opens mark. For some examples, let's focus on one industry that all of us deal with in a mobile context - Banking.

A Utility to Get Things Done Quickly

Don't wait to release your app until it does everything. Start with building one polished feature that makes someone's mobile life easier and get it out there. Ask your users for feedback on additional features they would like to see and deliver on the demand over time. But first and foremost - stop spinning. Build a utility first - not an app.

Here's a good banking utility example - Chase. Chase allows it's users to take a picture of a check and deposit it through their app.

That is awesome. It's a mobile use case that saves its' users minutes (if not hours) a week. Forget the balance lookup or any of that other me-too stuff. I would use this app if the mobile check deposit feature was the only function it provided. That feature makes a user awesome. I envy Chase customers because of this feature.

Answer a Question in a Local Context

Mobile users are on the go and are more-often-than-not looking for local information. For a (non-banking) example check out Do I Need an Umbrella Today. Click the icon, it comes up with a yes or no answer. Local, simple, meaningful.

I'll give you a bad banking example - Citibank. I have been a Citibank customer for 15 years. I like the bank, but I always have to hunt for a Citi ATM. I want an app that allows me to quickly find a nearby Citi ATM. I'm a pretty technical guy, but I have yet to be able to get Citi's iPhone app to work for me. It requires some convoluted registration on their mobile site (which I have completed) and it still doesn't work (until I call Citi support?). The bigger question is, why do I need to register to find an ATM? Make life easy for your users on the go. Only require security on information that needs to be secure.

Something to Entertain The Ego

OK, so your user is in line, on the train, waiting for a meeting to start, etc. "Entertain me, clown!" Unless you are a game developer you have some stiff competition. My suggestion - let them check their ego. People love checking their self-worth while they are bored (i.e. comments on their Facebook wall, LinkedIn connection requests, experience points on the social RPG game du jour, etc.). In the enterprise it's opportunities in the pipeline, forecasted sales bonuses, KPIs they are managing. So what information do you have that appeals to a user's ego? Provide it to them in a mobile context and they'll use it.

In the banking context Mint allows users to aggregate all their accounts so they can get a simple snapshot of their net worth. Their iPhone app provides a solid interface to this information.

I would change it slightly by proactively polling and aggregating account balances so they are available instantly (albeit delayed), instead of performing the sync on launch of the app, but the premise is solid. Show me my chops based on the latest stock tickers.

At the end of the day, the focus of apps needs to be on limited features in a mobile context. Find a utility that adds immediate value and get it out the door quickly. Provide a channel that allows mobile users to request additional features. Make your users part of your mobile product development. They won't steer you wrong.

Comments, experiences and perspectives below are always appreciated.