Last week I listened to an interesting podcast by Forrester analysts Mike Gualtieri and Jeffrey Hammond entitled Talent Matters: Why Application Development Cannot Be Industrialized.   At first I thought this could have been an anti-outsourcing discussion, but after listening and thinking about it, it’s really about a deeper understanding of the importance of having exceptional talent in your software engineering organization.  And it’s a concept that any technology-driven business – including travel technology companies, travel suppliers and travel distribution and intermediaries –  need to be thinking long and hard about.

The conversation can be boiled down pretty simply: application development and testing professionals are not a fungible asset.  Deep down (maybe we don’t have to go so deep), we all know this is true, yet every development project is estimated using the productivity of an “average” developer.  And worse yet, they refer to them as resources.  And according to Gualtieri and Hammond, this is where it all goes horribly wrong.  And they’re right.

It doesn’t matter what estimation method you use – Function Point Analysis, analogy-based techniques, parametric models  – these methods are used to estimate the man-months needed to complete the project.  But not all developers are the same.  There are rock-stars, low performers and everything in between.   So while an excellent guide, the accuracy of the estimates really depend on who are the members of the development team.

Art v. Science

In fact the best developers are ‘artists’ to borrow a phrase from Seth Godin’s latest book, “Linchpin”.  The boys from Forrester talk about attributes of the best developers: creative, passionate, disciplined.  But while artists may be the best developers, not all developers are artists. So as an industry, we have tried to put some more structure around the science of software development practices and to make software engineering a “profession”.  We have also leaned on methodologies and tools to enable average developers to deliver above average results.  It’s helped the industry move forward and develop great software.

The fallacy of the software factory

But the mistake that perhaps many firms make is to think that these methodologies and tools would turn their software development teams into software factories.  Nowhere has this approach towards trying to create software factories been more pronounced than in the IT outsourcing business.  That’s because under the traditional outsourcing model success (i.e. margins) is achieved by trying to break any task down into its most basic components so that those activities can be completed by the most junior and cheapest resources (there’s that word again).

This is not to say that methodologies, tools, reusable libraries are not valuable and don’t make software engineering teams more productive. But they’re not a cure-all for having good software engineers. Tools and methodologies are more like guiderails to reduce mistakes and help less-seasoned developers accomplish more advanced tasks, but don’t necessarily guarantee well written, high-performance software..   So I’m in general agreement with their point of view.  But I think it’s important to talk about software engineering maturity.

Software Product Engineering versus IT Application Development

Now let me shift the conversation slightly from a basic application development perspective (which Hammond and Gualtieri were focusing on) to a software product engineering perspective.  Let me start by saying that I believe that software product engineering is a different animal than developing IT applications.  Software products and platforms – whether sold directly to customers or simply provide the infrastructure to deliver your products or services to your customers – requires a complexity, a thoughtfulness, in development, nay architecture and design, that are not often found in applications designed for internal users.  And Forrester agrees. In fact they have written a report about how some companies whose businesses are technology driven, but don’t sell software per se, are starting to try to re-organize their software development organizations in the image of an ISVs R&D organization. Forrester calls these companies ‘product-centric’ and more and more travel companies of all stripes fit this description.

If you need a rule of thumb, think about who’s using the software in question: is it a customer – who may choose to switch to a competitor if they’re not happy with their experience or the performance of the app – or is it a app or other computing resource used by an employee whose only alternative is to find somewhere else to work? If it’s the former, you’re probably talking about an application that needs a more developed software product engineering approach.

Software product engineering activities differ from IT organizations because:

• They are more mature in software engineering practices when measured against maturity models like CMMi
• Adhere to formalized software engineering practices and use of common coding practices
• Recognize, appreciate, and adhere to release schedules
• Quality is of supreme importance.  Testing is important, but quality is designed in.
• QA teams use test planning, test strategy, as opposed to an ad-hoc approach to testing

I do want to avoid painting all IT organizations with too broad a brush. Some IT organizations are more mature than others and have put more investment into putting software engineering practices, focused on architecture and enforced adherence to coding standards across the organization.  However, it’s more likely that you’ll see that with teams whose code is tied closely to generating revenue or supporting the delivery of the company’s product or service to their customers.  They adopt a “product-centric” approach, as Forrester would say, to software development because they realize that bad software negatively impacts the company’s performance.

Talent Is Even More Important in Software Product Engineering Organizations

My firm, Ness Software Product Labs, is not the same as the big ITO firms. Our mission is to help extend and enhance the capabilities of software product engineering organizations – helping companies build and test software that drives revenues – rather than managing internal IT applications and infrastructure.  To accomplish that goal, Ness SPL believes that it requires a different philosophical approach from what you see from the large ITO firms. It informs the type of people we hire, the way we collaborate with our clients and the kinds of relationships and engagement models we employ.

But in the context of this subject, I want to focus on the talent issue again.  Software product engineering is not ITO.  Architecting, designing, building and testing products that are tied to revenue, that require high levels of performance, scalability and resiliency is not a task to be done by lowest-common-denominator individuals. We believe it requires highly talented individuals…artists with discipline.  We spend a lot of time developing best practices, solution accelerators, and identifying the best tools to use.  We spend at least as much time finding the right people and developing their talent and offer them challenges that most ITO firms can’t.  We don’t try to create a software factory, we try to create an environment where talented engineers can thrive.

And the crucible in which we do that work is not for the faint of heart.  We are part of the software engineering organizations of some of the leading technology firms on the planet: Amadeus the number one travel technology provider in the world; NAVTEQ, the leading mapping and location-based services platform, PayPal the leading alternative payments platform, OpenText a billion dollar Enterprise Content Management firm. And the list goes on.  Our approach and the talent that we hire is borne out by the clients who choose us to be a part of their R&D organization, not to run the plumbing.

Here’s your weekly reading list:

1. T2Impact’s Timothy O’Neill-Dunne tries to judge who’s right in the airline merchandising row.  Spoiler Alert: it ain’t the BTC.
2. American Airlines is trying to make GDSs, distribution channels to embrace XML in order to access ancillary services, which otherwise can’t be done prior to arrival at the airport.  However, American insists there will be no incremental costs to book via the direct connect channel.  GDSs probably don’t want to have to work through Farelogix, but also don’t want to modernize their feeds from EDIFACT to XML on a supplier-by-supplier basis.
3. Redmonk’s James Governor explains how VMWare isn’t getting into the relational database business, but that doesn’t mean they’re not in the database business.
4. First broken by BusinessWeek, it looks like Google is going to buy ITA Software for more than $1B, fully ushering in Google to the travel meta-search game (which they’re kind of in already with their recent integration of hotel results into Google Maps.  If this is true, it’s not good news for Kayak.com nor for Microsoft’s Bing Travel, the current leader in meta-search who also leverages ITA’s technology.  Good analysis on the rumor from Tnooz.
5. Altimeter Group’s Jeremiah Owyang breaks down the announcements from Facebook’s f8 conference.  Also check out Robert Scoble’s take on Facebook’s Ambition.
6. Does HTML 5 Herald The End Of RIA Plug-Ins? It’s behind the Forrester paywall, but I wanted to share it anyway.  It’s a pretty good analysis that separates the hype behind HTML5 from the reality that a lot of people have invested in RIA platforms and that HTML5 is still an emerging standard and therefore it will take a while to kill of RIA platforms like Flash.  However, the analysis doesn’t really take the rise of the mobile Internet.  I think it’s a pretty big miss and could act as a tipping point in favor of HTML5, but we’ll see.
7. HTC passes on Palm Buy. Not many options left. Lenovo? Motorola? Dell? My decision to by a Pre last summer is looking worse and worse.
8. Blippy offers a lame explanation of how credit card information ended up on Google. The “it’s less bad than it looks” line is the sort of non-apology apology that I have grown to expect and loath from companies and celebrities. What I’d like to know is whether Blippy went through PCI-DSS certification or if they even know what that is.
9. Apple tries to take over the travel industry next.  Great writeup by PatentlyApple.  But I’m not sure NFC will play as central as a role in reality as it does in the patent application.
10. 2 great posts by Don Dodge on what makes successful startups here and here.  Really nice to see him getting back to good content rather than shilling for Google.

In an earlier post about the hype around outcome-based outsourcing engagements, I talked about how it’s a great conversation starter, but doesn’t necessarily end up being the way that contracts eventually get written.  Not that it’s about bait-and-switch (although sometimes it is).  But it begs a question: how pervasive is outcome-based outsourcing?

Today I had an excellent, wide-ranging discussion with Forrester analyst Bill Martorelli about outcome-based outsourcing.  Bill is currently working on an upcoming research report about outcomes which he will be presenting at the Forrester Services and Sourcing Forum 2009 and we were comparing notes and I was looking for some feedback on the messaging I’ve developed for my company, Symphony Services.  We had a pretty big disparity in our estimates.  We were talking pretty broadly about the ITO and outsourced product development (OPD) markets, but I said that it’s probably less than 5% of total contracts, definitely less than 10 percent.  Bill thought that it was larger, perhaps twice that, but as we talked about what really counts as true outcome orientation versus simple output-based, fixed-time/fixed-price or SLA-supported contracts, he felt that my number probably wasn’t too bad.

But what this really highlights is that even some of the brightest minds in the business don’t have a good handle on how much of the outsourcing contracts are outcome-based.  What do you think is the right number, or do you think it’s just so much hype?