SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for October 31st, 2007

What is Talent if Not Good Design for Programmers? (Talent is No Myth for Programmers)

Posted by Bob Warfield on October 31, 2007

I love the Discipline and Punishment blog, but he’s taken a left turn at Albuquerque when he talks about the Myth of Talent for Software Engineering and then goes on to say:

What is the equivalent of “capital” in programming? It’s not ‘talent’ in any meaningful sense. Rather I’d suggest it’s what most people call “good design.” What’s really paying dividends in any large project is good design simply because design adds value faster than it adds cost. Good design, purely because of its “compound interest”-like nature, is largely what drives success in software and what separates successful projects from unsuccessful projects. The many software projects that fail (really they are abandoned) inevitably do so because of bad design.

I absolutely agree that it is the design and not the languages that matter most, but how else do we measure talent among programmers if not by good design?  Who do we look up to most among programmers we know?  It’s the Uber Architects.  These are the ones that have the good design ideas.  Yeah sure there are those guys who crank out devilishly clever but unmaintable code.  In the old days, they were called hackers, back before that term was a good thing.  It was a term of derision.  Great software engineers were the ones with great designs. 

Let me provide yet one more reason why talent matters.  If you really do believe it takes fewer people to write good code, and there is an overwhelming body of evidence to support that, how could you not also believe that if you have only a few slots on the team it means that talent matters even more?

In struggling to understand whether I’ve misunderstood the original post, I almost get a sense that the wrong meaning is being attributed to the word “Talent” when I see terms like “Rock Star Programmer” being thrown in as bad examples of “Talent”.  There are certainly situations where the talent label is misapplied to someone who in fact, does not have the talent.  Don’t blame that on the idea that talent is valuable! 

I sense a little bit of tendency to feel that the design is handed to programmers, and hence that’s why design and talent are separate.  That’s a bad idea!  Design is a participative process under the watchful eye of the right benevolent but fascist dictators.  A good dictator creates an overall framework that leaves a ton of freedom for individual programmers to express their own design sense in their corner of the world.  A programmer who just wants to be handed all the design detail on a stone tablet so he can “write code” is not someone I want to hire or work with on my small teams.  The guys I want will leave if they don’t get a hand in design.  You will understand a design so much more fully if you participated in creating it.  By the same token, I hate the idea of architects that never write a line of code because they’re too busy thinking of great architectures for someone else to build.

There is also a certain uncomfortableness with the idea that talent implies really great programmers are born and not made.  Let me lay that one to rest too.  I’ve hired hundreds of programmers to work on really difficult software in small teams and I have seen overwhelming evidence that great programmers, programmers with talent, are very definitely born and not made.  We’ve built languages and tools of all shapes and sizes, database servers, desktop application software, web software, data mining, genetic algorithms, and a host of other stuff ranging from the mundane to the completely weird.  I’ve worked with extremely famous programmers at companies like Borland, and I’ve worked with brilliant folks who are obscure.  The one area I don’t have experience with is games, but I think that world believes you’re born and not made too. 

Throughout those hundreds of programmers hired, only one pattern sufficed to hire more great programmers.  It had nothing to do with age or education.  It had nothing to do with giving them clever tests in the interview process.  It had to do with whether they’d ever done at least one great thing or not, and whether they could communicate that thing well enough to expose some native design sense.  I’ve seen guys with fantastic MIT or Stanford CS degrees (including graduate degrees) that could not program their way out of a paper bag.  I’ve seen high school dropouts that started programming relatively late code circles around the average CS grad. 

I’m sorry folks, but talent matters, talent is the ability to design software systems and algorithms, and you either got it or you ain’t.

Posted in software development, strategy | 5 Comments »

Serendipity is the Key to Code Reuse

Posted by Bob Warfield on October 31, 2007

In watching yet another ping pong game of compiled versus dynamic languages, I found myself mostly siding with the dynamic language crowd in the form of Steve Vinoski and Patrick Logan.  This time around the discussion was all about what to do with “average programmers”.  It all got started when some others posited that dynamic languages and RESTful architectures are for those who view progamming as art while statically checking the contract, whether speaking of languages or SOA’s, is what those who want to view programming as engineering should do.  I don’t want to get sidetracked by all of that background, because I will write about it some other time (is programming art or engineering, what to do with average programmes, yada, yada).  For this post, I was struck by one of the linked in tributaries that make the blogosphere such a powerful idea generator because it triggers that sudden tunneling of ideas between relatively unrelated spaces that sparks creativity.

Specifically, Vinoski mentioned almost completely in passing that REST is leads to serendipitous code reuse.  He provides just the one word, serendipity, with the link I’ve added to the word.  Well I can’t resist diving down a good looking rabbit hole when I see one, just to see what else there may be, and sure enough, it was worth the trip.  Stuart Charlton has a neat little post on serendipity and code reuse that crystallized some fuzzy thinking for me.  Stuart is an Enterprise Architect for BEA, which seems to me ought to predispose him to be much less enlightened, but being an INTP, I guess he couldn’t help himself blurting out some good stuff about REST.  Here is the goodness of Stu:

One problem with SOA is that it is very “heavy”, with a partial focus, like CBD before it, on planned reuse.

In some industries, planned “product line” reuse has been shown to work, such as with car platforms. It’s also appropriate for very general purpose programming libraries, etc., and could also be appropriate in software (there’s a fair amount of “software product lines” literature out there).

From this viewpoint, “build it and maybe people will use it later” is a bad thing. SOA proponents really dislike this approach, where one exposes thousands of services in hopes of serendipity — because it never actually happens.

Yet, on the Web, we do this all the time. The Web architecture is all about serendipity, and letting a thousand information flowers bloom, regardless of whether it serves some greater, over arching, aligned need. We expose resources based on use, but the constraints on the architecture enables reuse without planning. Serendipity seems to result from good linking habits, stable URIs, a clear indication of the meaning of a particular resource, and good search algorithms to harvest & rank this meaning.

This led my own little ESTJ overly top-down and logical mind to instantly make a list or continuum of choices surrounding code reuse, SOA, REST, and dynamic languages:

1.  Preplan everything and rigidly enforce the contracts:  Heavy SOA.  No hope for serendipity.

2.  Expose thousands of services in hopes of serendipity.  Lots of work if you use SOA-style mechanisms.  That’s why SOA proponents say it never happens.

3.  Use a lightweight protocol that exposes thousands of services almost for free: REST, we love you!

4.  Expose a language that can create any service as needed.  Whoa!  Where did that come from?

I’ll admit, #4 popped up unbidden.  In my defense, I have a sort of “Warfield’s Law” when it comes to computers that leaps to mind more frequently than it should:

All things become languages if they’re important enough.

If Adobe can make a language out of printing, I don’t see why this doesn’t merit a language too.  The Law is true too.  Computers do one thing especially uniquely: they are Turing machines.  Languages are their manifestation of that.  If it isn’t a language, it could be done by a toaster at some level and doesn’t need a real computer.  Conversely, if you don’t make it a language, you’re robbing yourself of the full power a computer can offer.

Getting back to the problem at hand, what could be better than a dynamic language for enabling serendipitous code reuse?  We can reorganize available code assets under the latest DSL of the day to solve an entirely new problem.  In the grand scheme of these distributed computing conglomerations, REST becomes the sort of assembly language for these DSL’s.  It gives us the universal impedance match we need to hook up our components.  The dynamic language massages that somewhat generic socket into something more recognizable and powerful for the particular domain we want to conquer today.  Tomorrow, we’ll build a new one, and it’ll be easy, because we have lots of RESTful components lying about and a nifty dyamic language that’s potent at composing them.

Perhaps I’ll run this thing on a Pile of Lamps while I’m at it.  I say that only partially in jest, because the Pile O’ Lamps crowd are speaking my language, at least in terms of making things into languages.  Aloof Schipperke writes that he sees SPOTs when thinking about the Pile of Lamps.  He goes through an abstraction exercise that got me thinking again.  Here is the original Lamp:

  • Linux
  • Apache
  • MySQL
  • P{HP,erl,ython}

Aloof says, “Wait, it’s more like this if we go up 10,000 feet”:

  • Scripting Language
  • HTTP
  • Operating System
  • Database

Do you see Warfield’s Law (everything becomes a language) at work yet?  What did the Scripting Language replace for many architectures?  The middle tier.  The application server.  Devilish complex, painful to operate, often extremely inefficient.  Beans of every variety abound.  J2EE et al ad nauseum.  Why put up with it?  Replace it with (drumroll please!):

A Scripting Language!

Now can we successfully combine all of these ingredients?   

  • Component Bus for Reuse and Communication:  (RESTful or similar) 
  • Scripting Language
  • HTTP
  • Operating System
  • Database
  • Utility Computing Infrastructure

That seems to me a potent next generation architecture for web software. 

Replacing pieces of code, framework, or whatever with a language is an extremely powerful chess move.  It’s turning a pawn into a queen.  It’s not easy to do, as most are not facile at creating languages.  But why bother, there are lots of nifty dynamic languages to choose from.  Now you’ve got another excuse to go look one up.

Posted in platforms, software development | 3 Comments »

Ubiquitous Social Networks for Business

Posted by Bob Warfield on October 31, 2007

Google’s OpenSocial API’s could make a lot of sense for Business.  I started thinking along these lines after seeing how many of the initial partners in the initiative were quite business related:   companies like Salesforce, LinkedIn, Plaxo, and Oracle, for example.  I asked how much longer would businesses swim upstream trying to use Facebook for business networking and communities if OpenSocial plugs directly into real business networks and communities?

This all begs the question of what would businesses do with Ubiquitous Social Networking?

Note that Google’s OpenSocial doesn’t get us there yet; it merely clears away the critical cross-Network linkage issues and lowers the barriers to write apps that will run on all participating networks.  Businesses still need easy to customize components that support the API’s to let them build special purpose Social Networks that they can live with.  I can’t believe that sort of thing is far behind, though.  Either Google will build it or someone else will. 

Let’s brainstorm a bit about what it means:

Let’s start out with the mechanisms by which many are introduced to businesses:  product registration and sales lead registration.  Let’s postulate for the moment that rather than this information disappearing into the black hole it usually does, what happens is you sign up to be a part of the community of customers and other interested parties the business is supporting via Social Networking.  So, you fill out the usual bit of information and perhaps a little bit more, and you’re on board. 

We don’t know at this stage enough about OpenSocial to say, but let’s even imagine that sign up is streamlined because the API’s can go back to the Google mother ship and save you re-entering data everywhere you go.  In that sense, perhaps it becomes the Universal Identity Fabric for the Internet that the ZDNet folks talk about.  Note that this is just getting you into community.  Anything that involves money changing hands or more security continues to operate as it always has and will remain secure and armor plated–no Open API’s needed there.

Now you’re part of a community.  You can participate in conversations with other community members and with the business.  Benefits?  Let’s see:

–  Improved Customer Service:  Some of the best and most responsive customer service I’ve ever seen comes not from huge companies but from communities.  Empower interested individuals to help their fellow customers with problems and make sure there is enough oversite so that if the help stalls or if wrong answers are given (or other noxious hijinks need attention) someone with the company picks up the thread.  I don’t know about you, but I much prefer online support to calling some faraway call center and fighting my way through some person who knows nothing but the script in front of their face.  It would be cheaper for the business too.

–  Faster Sales Cycle:  Great communities facilitate sales.  I’ve seen this over and over again.  The crudest form is classic Enterprise references, but it can be far far better than that with a real community.  Prospects get in and get infected by the enthusiasm.  Even if they see a problem, so long as it is worked out quickly, they’ll see it as a positive.  Chances are they’ll learn positives that no salesperson could ever think to give them as they watch what others are doing with products.

–  Customer Satisfaction:  People like to be part of a community.  It breeds loyalty.  Getting better Service and a happier Sales Cycle fostered by fellow loyalists being paid nothing all add customer satisfaction and loyalty. 

Given the initial entre, sub-groups can be a function of the community too.  This let’s business crowdsource all kinds of input from the customer base.  Interested parties will naturally gravitate in and out of the appropriate groups.  Whether the business is looking for input on what to build next or is actively trying to recruit new employees from these communities (often a fantastic source, BTW), it becomes much simpler for all concerned.

Okay, that’s a pretty conventional step up for some conventional processes.  But now let’s postulate what can happen if all of these business communities start to be connected via the Octopus that is Google.  Let’s assume that information can pass through the membrane below the surface of the API’s and go back to Google, where it gets repackaged into new services.  This is likely a voluntary process, but Google will be smart about making sure incentives are aligned to encourage as much sharing as possible.  They have a valuable soft dollar currency, BTW, in the form fo their ubiquitous advertising which virtually every business that has an online business must participate in.  If they have to, they can trade some of that to encourage the right behaviour.  My guess is they won’t have to.

What happens when we start the comingling?

Suddenly, we have cross-business knowledge of customers.  The benefits here are many as well.  Your office supplies source will already know which toner cartridge fits the printer you ordered and registered from Dell.  The camera store knows which accessories fit the new digital camera you got for your birthday.  The photography enthusiast site you’ve joined automatically offers to hook you up with the group of fellow enthusiasts who have the same camera.  They know from another photo site you’ve been visiting to hook you up with the landscape photography crowd rather than the portrait takers.  Because you have a membership with the National Audobon Society, you’re also steered to the wildlife photographers.

It’s almost creepy, I know, but it could also be strangely wonderful in terms of time saved and chance connections that never would have happened otherwise.  Why will businesses share their valuable information?  I know, it’s YOUR valuable information, but they see it as theirs and they’ll want you to sign off on it as such.  They won’t share contact information, but preference information remains pretty gray.  The reason they’ll share anything is they’ll be incented to do so.  Businesses could pay one another referral fees for successful transactions, for example.  That’s why the printer company is incented to tell the office supply outfit which printer you have and which toner works with it.  Google could use their ad dollars as a universal exchange currency to incent the behaviour.  Make it available to their ad engine and they cut you a break on your ads.  If they structure it right, it will be businesses trading Google ad dollars around and eventually spending even more of those dollars by making click throughs go up.

Google Operating System calls the new concept a “meta-Social Network”.  Stowe Boyd agrees that’s what it is.  I like that term, as that’s exactly what I think the long-term potential will be.

This is a beautiful example of using “open” to trump “proprietary”, and it will have far reaching consequences (although Stowe says it isn’t really “open” just “more open”).  Marc Andreesen called Facebook, “a dramatic leap forward for the Internet industry” and goes on to say, “Open Social is the next big leap forward!”  In that same post, he indicates the combined pool of users for the initial partners is about 100 million, which is 2x Facebook already.  So much for some of the early hand wringing over whether developers would find it interesting enough.  Scoble certainly views this as a threat when he asks, “Will Google Friendster Facebook?”  To learn more as a developer, Brady Forest has a succinct post over on O’Reilly.

It will likely take a couple of iterations and perhaps even some new API’s before the full vision I’m painting can be realized, but the starting gun has been fired.  I’m reminded of the seen in the movie Trading Places where the Duke’s are explaining commodity trading to Eddy Murphy.  The “good part”, as they call it, is that the traders make money whether the commodity is going up or down so long as people are buying and selling.  Google owns this commodity exchange, and OpenSocial is going to make it even more valuable while spinning off benefits that will make the web much more intelligent and aware of everyone’s personal choices.

Related Articles

What’s Next Google?  (You won the battle, now what about the war?)

Google is in the Cat Bird Seat for Identity Matching With OpenSocial

Posted in Marketing, strategy, Web 2.0 | 9 Comments »

For Google, The Internet Is Their Social Network (Plus, Business Communities and Cookie Marketing)

Posted by Bob Warfield on October 31, 2007

For Google, the Internet literally is their Social Network. I first made that pronouncement in a post on whether the giants should buy, build, or integrate, and it looks like Google does indeed want to make the Internet their social network.  Their chosen vehicle for doing this is a set of open apis to be announced tomorrow called “Open Social”.  If a social network agrees to participate and offer these api’s, developers will be able to access them to do three things on the network:

  1. Access profile information about the user.
  2. Access friends data for the user, the social graph, in other words.
  3. Access activities, such as news feeds.

Applications (widgets for social networks, in other words) can be created using these api’s without recourse to any special markup languages such as most networks currently require.  Instead, normal Javascript and HTML are used.  This will make it easier to port existing applications to use the api’s and play on participating social networks.  The host social network gets to set its own rules about things like advertising and other policies in the apps. 

The charter hosts form quite a potent group and include Orkut, Salesforce, LinkedIn, Ning, Hi5, Plaxo, Friendster, Viadeo and Oracle.  Charter applications include Flixster, iLike, RockYou and Slide, which are some of the key apps from Facebook.

This marks quite a warning shot across the bow of Facebook.  The timing is interesting.  Google probably could have impacted Facebook’s recent financing by preannouncing, but they chose not to.  I think it’s a more clever strategy because it creates a more intangible fear.  If Facebook had gotten funded at their desired valuation anyway, they could downplay the whole Google thing and say the world had voted with their pocketbooks that it didn’t matter and they still got a $15B valuation and $500M in cash.  Moreover, Google may have acted as a spoiler to get Microsoft to commit to Facebook, only to pull the rug out from under them with an open strategy.  Proprietary Microsoft is in bed with proprietary Facebook and out in the cold with the rest of the web.  Doh!

For Google, the Internet is its Walled Garden.  Why should it create sub-gardens?

There are lots of ramifications to ponder including Business Communities and the future of Social Network Marketing.  The mouth waters at the possibilties OpenSocial may bring.  It’s hard to see how Facebook can compete with this simply by adding groupings to their own world.  Google has turned the walled garden inside out with this new api.  A couple of brief notes follow.

Business Communities 

Take special note of the business players in the mix, companies like Salesforce, LinkedIn, Plaxo, and Oracle, for example.  First thought is how much longer will businesses swim upstream trying to use Facebook for business networking and communities if OpenSocial plugs directly into real business networks and communities?

I think there is a huge opportunity for businesses to get hooked up with communities, and Google is going to be right in the middle of all that as are these early movers to the platform.  Imagine the possibilities to be had by linking these kinds of disparate services into collaborative uber communities.  What if companies use this as a mechanism for product registration and introduction to their own communities?  What are the possibilities for tying all of that together?  And how can Google’s advertising machine take advantage of such goings on?

Of Dirty Cookies and Social Network Marketing

Speaking of advertising, there’s been a lot of news lately about Facebook’s “Social Ad Network”.  The idea is that Facebook will plant cookies that tell other sites you visit what your interests are so they can better target ads to you.  Presumably, Google could make use of this api to completely short circuit Facebook’s Social Ad Network by tying their knowledge (via the api) of your profile and interests back to their own AdSense system.  You’ve got to figure the combination of knowing the profile across potentially multiple social networks together with tying into AdSense’s other insights would produce a truly killer ad platform.

There’s one tiny little fly in this ointment for either company, and that’s the idea that for some people, such “dirty cookies” are downright creepy from a privacy standpoint.  I have to admit, I am somewhat in that camp myself.

Interesting times we live in.  If these antics manage to build a box around Facebook that caps it’s potential, we will be seeing yet another hole in the bubble that will start to let some of the momentum leak out.

Related Articles

Ubiquitious Social Networking for Business

Robbin Harris says Google Bluffed Microsoft into Overpaying.  I agree, as I mention above, Google played this one in a very clever way.

Posted in business, strategy, Web 2.0 | 7 Comments »

%d bloggers like this: