FILive: The Culture War Myth: Startups in the Enterprise

Jeffrey Burlin @pwcinnovate  PWC consultant and leader of their internal innovation lab.

I try to mix it up in terms of the types of sessions I attended, but this one definitely fits well with my work situation in a big enterprise.  Plenty of other people attended this session also, so it must have resonated well with many.

30 years ago the difference in culture between enterprise and innovator was cut and dried.  Nowadays it’s not so clear cut.  Jeffrey shared a couple of company profiles without sharing their name and asked the audience to vote via twitter on whether it was a startup or an enterprise company.  Needless to say, the crowd was wrong.  For instance, what would you judge this example?

Twitter  – has 900+ employees, 350m in revenue, based in California.  Startup or Enterprise?

So what’s the motivation to act like a startup?  Personally, the reasons that resonate with me are the benefits to employee culture (working on stuff that matters, clear goal, small motivated team, flexibility in technology) and better products as a result.

So how are enterprises dealing with innovation?  Jeffrey sees two models for bringing a startup mentality to the enterprise:

  1. Outsourcing like Blue Cross Blue Shield’s arrangement with Sandbox in Chicago
  2. Internal Innovation Labs.  If I recall, Walmart kickstarted theirs by acquiring a small company or two they viewed as innovative.

Requirements for starting an internal innovation lab:

  • Executive Support – Introductions, funding, etc.
  • Freedom to Fail.  Not every project will succeed.  In fact many may not.
  • Single decision maker for whether the project proceeds
  • Avoid the HiPPO (Highest paid person’s opinion) and allow the single decision maker above to decide how things proceed.
  • Agility and ability to adapt to changing circumstances
  • Postpone ROI-driven decision making.  That’s not to say ignore, but postpone.

Random statistic: Walmart has ~1500 in eCommerce.  Holy crud!

Good session.  This’ll give me plenty to think about going back to work.


FILive: Jeff Atwood – I fought Atwood’s Law

Jeff Atwood, author of the CodingHorror blog, Stackoverflow creator and generally opinionated guy did the Thursday morning keynote.  A few random thoughts to start out:

  • Stackoverflow was an answer to Experts-exchange.  Experts-Exchange had lots of cool stuff, but it was stuck behind a paywall.  Slightly frustrating when google returns enticing results, only to not be able to see the answers.  I can vouch for that.  I actually used to use free points and stuff I’d scrounged to find answers off of it.  Never paid for it though 🙂  And yet Stackoverflow and derivatives seem to be very commercially successful. 
  • Web 2.0 meant “javascript now works” 🙂

A little on Javascript:

Javascript has won not by technical merit particularly, but by default. It was there.  With every computing platform having one or more browsers, Javascript was there.  Browser makers had an incentive to make it FAST, and even open source like Google’s V8 javascript engine which is the runtime for Node.js.  Plus, it’s cool since you can always view the source for stuff coming down to the browser.  That’s true “open source” in at least one meaning of the phrase.  And Javascript forgives you too.  Pretty low barrier to entry.  All that adds up to a nice recipe of becoming incredibly popular.

Everybody wants a law named after themselves.  It’s human nature.  So here we go – Atwoods law:

Instead of the traditional “All software grows until it can read email”, Jeff believes  “Any application that can be written in Javascript, will eventually be written in javascript”.

So is javascript ok for mobile devices?  Based on the charts he showed, browser and device performance is doubling still, unlike desktop performance and is in his opinion good enough even now. He also argues native is problematic because of the pain in finding, updating. Do you agree?

Of course, this XKCD cartoon on native apps is very appropriate, although I like it better from a usability antipattern example:

Jeff was looking to scratch an itch not scratched by StackExchange.

  • Stack exchange is optimized for learning, not hanging out.
  • Discourse is designed to allow conversation.  Open source forum sw.  He calls it a “discussion platform”.
  • Jeff was looking seriously about using javascript for the whole thing. Here’s an interesting quote: “It’s fun to be a polyglot, but shifting gears!”  
  • Node.js was definitely a front-runner, but for him the show-stopper was that Node lacks packaging.  Jeff really likes Ember.js for the client side.

So the question would be, did he use javascript for the whole project in question?  No, Ruby on Rails.

FILIve: Experience Driven Development and Contract First Development

SuAnne Hall and Ryan McGinty from Effective UI.

Contract-First Development

Overall, these two did a good job presenting a case study of a site redesign engagement their company recently completed.  If I’m remembering correctly (without the slides in hand), they were doing primarily the front end work.

SuAnne started out by explaining their approach.  They drove the requirements from the user experience perspective, back to the other layers of the application.  I’ve seen projects done in this manner, and oftentimes it can be very effective.  Here’s their reasoning on why it was appropriate in their case:

Why Experience Driven?

  • Ensures it makes sense to the user since it’s focusing on how the user will interact. (And it’s not good enough to guess at what the user wants: Gotta ask the users.)
  • Should result in a user-friendly good user experience moreso than an approach that comes at it from a different angle like the company’s internal business processes. Should be personal, engaging, contextual, communicative, simplifying.

Haha. They brought up photojojo and the “do not pull” handle.  Try it out. Gotta love mixing a little humor into a product.  Makes me love it!

Contract- first development

I found it interesting that Contract-first got a mention at this show, being that most of the time I’ve heard it discussed more in development circles.  However, it makes sense in their situation.  By pulling apart the components on the wireframes and defining contracts between the ui side and back end side, they were able to leverage the different groups working on the separate parts.  I’m trying to see how this would directly help in quite the same way in a group where the whole team were generalists and working interchangably on both front and back end, but I love having clear separation between layers.  Services can be a beautiful thing.

Next, Ryan showed an interface definition.  JSON in this case.  I believe they used JSON Schema to help define and possibly JSON hyper schema.  I haven’t played around with either, so add that to the list.

Ryan pointed out lots of MVC javascript libs that might be useful.  Angular, JQuery, Backbone, etc.  I’ll need to ponder those a little especially in the context of applications that aren’t a clean slate.  Websphere Commerce for instance.

One final takeaway I got from this was a reminder to focus on the error handling and edge cases ASAP in the process!  Good point, and one that I’ve violated more times that I’d want to admit.

Good presentation.