Stop Selling Software Development Short

With custom software development needs increasing everyday and a global market ready to compete for these projects on an outsourced basis, a looming question arises: Has software development become a commodity?

And recent failed implementations, even by highly reputable and respectable enterprise software makers, offer insight into the need for a non-commodity approach to software development and deployment:

SAP has been slapped with a lawsuit by California’s state controller over a payroll software implementation the office says cost taxpayers a vast sum of money, but has never worked correctly. SAP stands by its product, noting that the “software works exactly as it is designed,” but that presupposes that the software was the right fit, right off the shelf, in the first place

Not to pick on SAP, but Avon’s failed implementation showcases how cookie cutter enterprise software is failing to offer the easy user experience that modern software customers need

Several DOD ERP systems undergoing program integration are experiencing difficulties similar to those that eventually led to the termination of the Air Force’s Expeditionary Combat Support System (ECSS) – for example, the Defense Enterprise Accounting and Management System (DEAMS), the Navy ERP, and the Common Aviation Command and Control System (CAC2S) have all failed to adhere to crucial BPR guidelines and acquisition best practices, resulting in substantial cost overruns and scheduling delays

Can knowledge based services become a commodity?

I am in the software development business, and even I receive quite a few emails a month from companies trying to sell me custom software development services. The emails are remarkably similar in format: “Dear Carlos, my name is Business Person. We offer awesome software development services for $X an hour. They are ready now. How many do you need?”

For someone who is not intimately familiar with software engineering or intellectual property, these types of emails suggest that software creation is a commodity service or product. They might think that all products resulting from software development projects are created equal: an iPhone App costs $X, an Android App costs $Y, and a Web Application costs $Z.

Development is as much art as science. Give five different software developers the same problem to solve and you will get five different solutions. Because software development does not follow a fixed set of rules or procedures, the engineers behind software projects deliver widely disparate software products. This means that companies working with remote teams will get different results from one solution provider to another.

Is one solution better than the others? Nearly always. Will all solutions solve the problem equally well? Almost never. Given this reality, the vast majority of software development cannot be a commodity: the products are never exact substitutes for one another, and it’s not just a question of comparing apples to oranges. It’s more like comparing high-grade, freshly picked apples to bruised ones that have been in cold storage since last season.

To be a fair, some software development solutions have no differentiation across the market and can be considered a commodity. Take for example a content management system (CMS), payment gateway, or even a relational database management system. The differentiation between some of them can be small and difficult to find, and based on very specific use-case requirements.

This is the decade of the developer, not the decade of development. The proliferation of software is happening because highly trained engineers are practicing a craft that is not easily replicated or replaced: technology breakthroughs are, at their core, driven by human innovation.

Software development cannot be a commodity because it’s not determined merely by the what or the how much. It’s equally determined by the who – the people behind the projects.

If this is the decade of the developer, I’m calling for a new approach to budgeting for development projects. The value of great people can be hard to measure, but in the decade of the developer, it must play a role in every organization’s decision to build – or buy – great software.