Software is about to eat the NYSE

The renowned VC firm, Andreessen-Horowitz, formulated a hypothesis in 2011 that "software is eating the world". Their hypothesis has since spawned many versions such as software eating fashion, software is feeding the world and, my personal favorite, Jack Dorsey is eating payments. Software however can have less of an appetite depending on where you do business in the world.

New York City's financial businesses have always been harder to access for software startups due to a number of factors (of which, I'm sure, culture and incentives play some part). One such man, Jeffrey Sprecher, appears to have broken through that divide and was profiled in the New York Times on Sunday, January 20th, 2013. The NYT article is a great story on business success, but embedded within it is the notion that software is currently "eating trading" (that is, the art of human trading within exchanges) and software will eventually eat the vast majority of this human activity over time. An important consequence of all this trading exchange gastronomy is that wealth gets redistributed more quickly to the victor... in this case, it is Mr. Sprecher and his firm ICE: IntercontinentalExchange.

After reading the NYT article, I'm reminded that the best software products aren't always enough for success. Technology alone conquers nothing; timing and deep market insight are the other essential pillars which, when combined with technology, create a powerful catalyst for creative destruction. As markets begin to shift, new opportunities arise. Those of us who see these opportunities more clearly (and that's really the hardest part) have the ability to act by finding a software-based solution that fits that opportunity. This software then has the ability to eat just about anything in its path towards profitability.

Mobile Development Trends

:: Facebook on Android vs. iPhone Trend

A colleague of mine, Marwan Haddad, sent me an insightful article today about a poster that was recently seen at Facebook:

Many engineering teams are currently engaged in mobile development and because of this, mobile user trends are very important to keep track of so that each of us ends up building the right mobile applications today and hopefully as far into "tomorrow" as possible. Trends are shifting quickly as new users enter the smartphone market, decide to switch devices or simply change their overall mobile behaviour.

Facebook's poster (or really the IDC) is projecting quite far into the future as the date when this poster was mostly likely seen was around November 2012 (which puts us somewhere in the middle of the graph). The projection spans approximately 3 years from today till somewhere in 2016. In the technology business that's a very very long time to project anything as few people really know what will happen in 1 year from now let alone 3 (the iPhone 3GS was released just over 3 years ago and now look where we are with Android phones dominating). Maybe Windows Phone, the forthcoming Firefox OS or even a yet unnamed player will be lucky enough to steal some market from Google or Apple but really only time will tell. All I know right now is that the competition among these tech giants is fierce and as a result its producing an upward spiral of innovation within the smartphone market which all of us will benefit from for years to come.

The really interesting nugget of information within that Facebook poster projection is the dominating trend that Android currently has over iPhone and looks to have and increase in the months/years to come. If you or your company is still solely focused on iOS development at this point it may be worth reconsidering where the bulk of your customers are today let alone tomorrow. There was much talk way back when about Open vs. Closed Platforms and many predicted that even with Apple's initial dominance Android's "open system" would eventually prevail and it looks like that prediction is happening in full force (for the foreseeable future at least).

:: Kleiner Perkins' Mary Meeker on Mobile Trends

For an even deeper analysis of various Internet and mobile trends, Mary Meeker's year end trend report is an absolute gold mine of information. I've included a screenshot of slide #16 below where she notes that Android phone adoption was nearly 6x that of the iPhone... WOW.

:: TechCrunch's MG Siegler on Building for Mobile 

TechCrunch's MG Siegler wrote a post on Dec 11, 2012 titled Mobile Burst where he argues that "the mobile device is a different beast than a computer". He believes that companies/developers should focus a large amount of their resources on building the right type of user experience that is not only optimize for, but created exclusively for mobile use. In that post he links to his own personal blog post where he makes some very pointent statements:

• "Don’t build an app based on your website. Build the app that acts as if websites never existed in the first place. Build the app for the person who has never used a desktop computer. Because they’re coming. Soon."

• "What matters is that in the next five years every person on this planet is going to be using a mobile device. And these devices are going to be used far more than any traditional computer ever has been and ever will be."

So whether you're building mobile applications with HTML5 or going native, make sure to build the right experience for that specific mobile form factor instead of replicating or mimicking what you've previously built for the desktop.

:: Updates

Following on from MG Siegler's article above, here is an interview with Vibhu Norby on TechCrunch TV who disagrees that Mobile is unanimously the future of all development.

Megan Quinn of Kleiner Perkins Caufield & Byers (who formally worked at Google and Square) was interviewed on TechCrunch TV and had some things to say about the emerging mobile landscape:

• "mobile is not an evolution this is a revolution."
• "every human activity is being re-imagined through the prism of a mobile device"

She went on to say that the 3 areas of mobile development that are seeing huge potential are: Education, Consumer Health and the Internet of Things.

Another Mobile Internet assessment from Business Insider called "The Future of Mobile".

.NET Code Contracts: Invariants Explained

I have recently started using .NET Code Contracts. I love the streamlined approach to implementing pre-conditions and post-conditions that previously required multi-line if statements along with the ability to check coding assumptions statically and even at runtime (release or debug builds). .NET Code Contracts are another valuable tool in a software engineers arsenal to combat the growing complexity of software systems.

The latest MSDN magazine (June, 2011) has an thorough article on invariants which are an element of .NET Code contracts. The article will go into much more detail but essentially invariants allow for the verification of an object's internal state before and after a set of operations. To create an object invariant, a class simply needs to contain a new private method with the ContractInvariantMethod attribute and then specify any conditions within the private method that should hold true before and after any operation on the class or instances of the class. Here is an example of what the object invariant method would look like for a class called News which has internal state for the Title and Body of a news article:

[ContractInvariantMethod]
private void ObjectInvariant()
{
     Contract.Invariant(!String.IsNullOrEmpty(Title));
     Contract.Invariant(!String.IsNullOrEmpty(Body));
}

What this accomplishes for programmers is that if they inadvertently try to alter the internal state on an instance of the News class to something it should not be (such as setting Title = string.empty), the .NET Code Contract static checker will warn the programmer that they are violating the object's invariant.

Thus, programmers can now design and build classes with the help of .NET Code Contracts that enforce correct API usage. This is a very powerful feature that will avoid subtle bugs from ever occurring.

Designing Scalable Systems

Many software based problems with large amounts of persistent data have already, or are currently, out growing the typical design of a single database for all persistence requirements. The need to build scalable software systems is becoming paramount as the amount of data that software applications deal with grows and as we move software applications to the cloud where the addition of more distributed computing power is only an API call away.

Ricky Ho has put together a comprehensive list of general principles and common techniques to use when designing scalable systems. It's a great list to reference while thinking about and designing new components for a software system that is required to scale.

Coding the Architecture

I recently found this website called Coding the Architecture. They have an online book full of resources on how to approach, document and refine software architecture. The information contained on the site is simple, concise and backed by some experienced software developers.

One of their ideas/practises I find particularly compelling is what they call 'C4' otherwise known as context, containers, components and classes. The authors highlight the usefulness of decomposing the architecture of an entire software system into 4 separate architecture diagram types. This separation helps development teams understand their software system(s) more clearly by only showing a specific view of them. By reducing the amount of information you put into a single "architecture" diagram, the more easily it is to digest, understand and then act upon.

They also recently blogged about a similar topic in a post called Deliberate practise, effective sketches.

State Machines and Regular Expressions

I came across a great article by Mark Shead about state machines, computer science basics and regular expressions. It really helped me understand the theory behind regular expressions and helped me realize why I wouldn't be able to use them to match strings embedded within double quotes that were data fields within a CSV file.