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.