Software companies love hiring people that like solving hard technical problems. On the surface this seems like a good idea, unfortunately it can lead to situations where you have people building a product where they focus more on the interesting technical challenges they can solve as opposed to whether their product is actually solving problems for their customers.

I started being reminded of this after reading an answer to a question on Quora about the difference between working at Google versus Facebook where Edmond Lau David Braginsky wrote

Google is like grad-school. People value working on hard problems, and doing them right. Things are pretty polished, the code is usually solid, and the systems are designed for scale from the very beginning. There are many experts around and review processes set up for systems designs.

Facebook is more like undergrad. Something needs to be done, and people do it. Most of the time they don't read the literature on the subject, or consult experts about the "right way" to do it, they just sit down, write the code, and make things work. Sometimes the way they do it is naive, and a lot of time it may cause bugs or break as it goes into production. And when that happens, they fix their problems, replace bottlenecks with scalable components, and (in most cases) move on to the next thing.

Google tends to value technology. Things are often done because they are technically hard or impressive. On most projects, the engineers make the calls.

Facebook values products and user experience, and designers tend to have a much larger impact. Zuck spends a lot of time looking at product mocks, and is involved pretty deeply with the site's look and feel.

It should be noted that Google deserves credit for succeeding where other large software have mostly failed in putting a bunch of throwing a bunch of Ph.Ds at a problem at actually having them create products that impacts hundreds of millions people as opposed to research papers that impress hundreds of their colleagues. That said, it is easy to see the impact of complexophiles (props to Addy Santo) in recent products like Google Wave.

If you go back and read the Google Wave announcement blog post it is interesting to note the focus on combining features from disparate use cases and the diversity of all of the technical challenges involved at once including

  • “Google Wave is just as well suited for quick messages as for persistent content — it allows for both collaboration and communication”
  • “It's an HTML 5 app, built on Google Web Toolkit. It includes a rich text editor and other functions like desktop drag-and-drop”
  • “The Google Wave protocol is the underlying format for storing and the means of sharing waves, and includes the ‘live’ concurrency control, which allows edits to be reflected instantly across users and services”
  • “The protocol is designed for open federation, such that anyone's Wave services can interoperate with each other and with the Google Wave service”
  • “Google Wave can also be considered a platform with a rich set of open APIs that allow developers to embed waves in other web services”

The product announcement read more like a technology showcase than an announcement for a product that is actually meant to help people communicate, collaborate or make their lives better in any way. This is an example of a product where smart people spent a lot of time working on hard problems but at the end of the day they didn't see the adoption they would have liked because they they spent more time focusing on technical challenges than ensuring they were building the right product.

It is interesting to think about all the internal discussions and time spent implementing features like character-by-character typing without anyone bothering to ask whether that feature actually makes sense for a product that is billed as a replacement to email. I often write emails where I write a snarky comment then edit it out when I reconsider the wisdom of sending that out to a broad audience. It’s not a feature that anyone wants for people to actually see that authoring process.

Some of you may remember that there was a time when I was literally the face of XML at Microsoft (i.e. going to took you to a page with my face on it Smile). In those days I spent a lot of time using phrases like the XML<-> objects impedance mismatch to describe the fact that the dominate type system for the dominant protocol for web services at the time (aka SOAP) actually had lots of constructs that you don’t map well to a traditional object oriented programming language like C# or Java. This was caused by the fact that XML had grown to serve conflicting masters. There were people who used it as a basis for document formats such as DocBook and XHTML. Then there were the people who saw it as a replacement to for the binary protocols used in interoperable remote procedure call technologies such as CORBA and Java RMI. The W3C decided to solve this problem by getting a bunch of really smart people in a room and asking them to create some amalgam type system that would solve both sets of completely different requirements. The output of this activity was XML Schema which became the type system for SOAP, WSDL and the WS-* family of technologies. This meant that people who simply wanted a way to define how to serialize a C# object in a way that it could be consumed by a Java method call ended up with a type system that was also meant to be able to describe the structural rules of the HTML in this blog post.

Thousands of man years of effort was spent across companies like Sun Microsystems, Oracle, Microsoft, IBM and BEA to develop toolkits on top of a protocol stack that had this fundamental technical challenge baked into it. Of course, everyone had a different way of trying to address this “XML<->object impedance mismatch which led to interoperability issues in what was meant to be a protocol stack that guaranteed interoperability. Eventually customers started telling their horror stories in actually using these technologies to interoperate such as Nelson Minar’s ETech 2005 Talk - Building a New Web Service at Google and movement around the usage of building web services using Representational State Transfer (REST) was born. In tandem, web developers realized that if your problem is moving programming language objects around, then perhaps a data format that was designed for that is the preferred choice. Today, it is hard to find any recently broadly deployed web service that doesn’t utilize on Javascript Object Notation (JSON) as opposed to SOAP.

The moral of both of these stories is that a lot of the time in software it is easy to get lost in the weeds solving hard technical problems that are due to complexity we’ve imposed on ourselves due to some well meaning design decision instead of actually solving customer problems. The trick is being able to detect when you’re in that situation and seeing if altering some of your base assumptions doesn’t lead to a lot of simplification of your problem space then frees you up to actually spend time solving real customer problems and delighting your users. More people need to ask themselves questions like do I really need to use the same type system and data format for business documents AND serialized objects from programming languages?

Note Now Playing: Travie McCoy - Billionaire (featuring Bruno Mars) Note


Friday, August 27, 2010 5:55:21 PM (GMT Daylight Time, UTC+01:00)
Article was good until I got to this paragraph which definitely needs a little attention:

"It should be noted that Google deserves credit for succeeding where other large software have mostly failed in putting a bunch of throwing a bunch of Ph.Ds at a problem at actually having them create products that impacts hundreds of millions people as opposed to research papers that impress hundreds of their colleagues. That said, it is easy to see the impact of complexophiles (props to Addy Santo) in recent products like Google Wave."
Friday, August 27, 2010 6:44:49 PM (GMT Daylight Time, UTC+01:00)
You can't fault polished, solid code :)
But seriously Wave failed as a product because it couldn't find a niche and simply because there are are products (skype, im, collaboration suites) which do a better job. Company culture doesn't really have to do anything with it. Google's wikipedia clone wasn't also a successful product but that doesn't have to do anything with the company culture.
Friday, August 27, 2010 7:56:35 PM (GMT Daylight Time, UTC+01:00)
You can't fault polished, solid code :)

Sure you can! If the time spent on polishing and solidifying it keeps it from getting to market in a timely fashion, or if polishing and solidifying adds so much expense to a profitable product that it becomes unprofitable, then the polishing and solidifying hurt you more than it helped.

It's like Tom West said 30 years ago in Tracy Kidder's excellent book, The Soul of a New Machine: "Not everything worth doing is worth doing well."
Friday, August 27, 2010 7:57:56 PM (GMT Daylight Time, UTC+01:00)
Amen. It's important to remember that a product has to solve a problem.

Google Wave is very, very cool. But it doesn't solve any problem in communication that I had or (clearly) that many other people had.
Friday, August 27, 2010 8:18:47 PM (GMT Daylight Time, UTC+01:00)
@Marius: Speaking as someone who's used (and continues using, in willful ignorance of its cancellation) Wave very heavily in his work life, I'm afraid I must take exception to the statement that "products (skype, im, collaboration suites) [...] do a better job". There are a lot of reasons for Wave's failure to take off quickly, but it really was well on its way to doing an excellent job pulling the pile of crap that is mailing-lists/im/irc/shared-docs/etc/etc into a coherent whole. A lot of polish remained to be done, but I absolutely dread having to go back to these other modes of communication.
Friday, August 27, 2010 9:04:49 PM (GMT Daylight Time, UTC+01:00)
This article lacks important information to make good conclusions, such as the decisions that led Google to pursue Google Wave, and the product development process they took when building it. Assuming they did it for no other reason other than to solve a hard technical problem is a serious insult to their intelligence.
Saturday, August 28, 2010 1:56:00 AM (GMT Daylight Time, UTC+01:00)
David Braginsky wrote that quote that you cited.
Saturday, August 28, 2010 2:06:43 AM (GMT Daylight Time, UTC+01:00)
Comparing Wave to mailing-lists/im/irc/shared-docs/etc is way off the mark. The beauty of wave is in its modular architecture which allowed integrated extensibility. What does that mean? It means that people with some skill could extend Wave to support their specific needs and still inherit the platforms collaborative nature.

The mistake - the bulk of the interest (tech media driven) was in getting people to just jump on the thing and ride it, versus seeking out those who would pick it up and spend some time leveraging the platform to specific uses.

A group I worked in spent a lot of time building an extensible collaborative laboratory information system and scientific data management and analysis system. If we had access to a platform like Wave to front this, we would have been ecstatic and happily just concentrated on the back-end scientific analysis and the implementation of a few custom wave components to present, share and distill findings to foster scientific discovery.

Have a look at

Saturday, August 28, 2010 3:56:54 AM (GMT Daylight Time, UTC+01:00)
The Quora answer is misattributed to Edmond Lau; the author is actually David Braginsky. Edmond confirmed this to me in a message.
Saturday, August 28, 2010 3:45:49 PM (GMT Daylight Time, UTC+01:00)
Wave is a great collaborative platform. From technological point of view - this is the future that somehow came into present. From marketing and design point of view - it is disaster. However, even with all mistakes made - Wave platform is so advanced - that it can easily take life of its own and become the greatest success. Despite all mistakes in marketing and client design in the aspect of user experience. It just needs more time - about 2 years more. I speak as a outside developer that created a few Wave extensions - the potential is huge.
Sunday, August 29, 2010 6:39:25 AM (GMT Daylight Time, UTC+01:00)
REST vs SOAP is a bit misleading. JSON-RPC uses JSON, is an alternative to SOAP, and in many ways is simpler (or at least less pedantic) than REST.
Sunday, August 29, 2010 9:05:37 AM (GMT Daylight Time, UTC+01:00)
It depends. You cannot just hire people only to solve customer problems unless your business only focus on well established commodity technology products. There should be some small subset of teams to r&d and then make a product prototype to be handed over to next phase if there is one. Mistakes should be tolerated or even encouraged for this. But way too often managers who excel
at managing daily tasks, often lack the guts to set aside and protect certain budget for experienment even if those projects are high risk and got high failure rates. Often these two areas command people with siffernet mind sets and there are just very few in the industry who get both.
Tuesday, August 31, 2010 1:07:26 PM (GMT Daylight Time, UTC+01:00)
Thanks very much for this great article. We are a Company that recruits and manages channel partners for IT Companies in Europe and in the US. We often face the situation of a startup that strives to develop their business without a clear view of their value proposition. Of course, they hardly succeed as partners are not much interested in disrupting technologies (that means long sales cycle) but in solutions that solve their actual customers' concerns. This is why, we are now delivering business courses that start with refreshing (or teaching) about Competitive Value Proposition.
I found your post illustrating very well a flaw that a poor value proposition may lead to and with your permission I'll quote some of your assessments.
Best regards
Wednesday, September 1, 2010 8:44:49 AM (GMT Daylight Time, UTC+01:00)
Saturday, September 4, 2010 6:17:12 AM (GMT Daylight Time, UTC+01:00)
It's nearly impossible to rival with other Internet sites, if your Internet site isn't optimized. The one way out is to find the bookmarking submission service, which will modify any Internet site.
Saturday, September 4, 2010 4:31:18 PM (GMT Daylight Time, UTC+01:00)
Liebe Grüße aus Berlin. Werde diese Seite im Auge behalten, gefällt mir ganz gut. Weiter so :o)
Comments are closed.