Spencesite

The Future of Software Development, Part II

// February 22nd, 2008 // 1 Comment » // Emerging Tech

The coming disruption the big software companies are blind to…

In my last post, I laid out the reasons as to why software development was about to experience a serious disruptive force. I made the argument that open source software, while highly valuable, couldn’t continue to try to live outside the economic realities of our real world lives. But OSS has obviously worked: look at the successes we’ve seen to date. And I concede the point. However, I believe that OSS has been able to carve out a niche because there have, up until now, been no viable alternatives. And that may actually be changing…

Enter SaaS Marketplaces, Collaborative Development Environments, and The Future.
Which is where SaaS marketplaces enter the picture: what if there were online environments where developers could create, collaborate, and connect? What if they could have a central “hub” which allowed them to connect with potential employers? What if they could collaborate on common components, assemble those components into larger entities (i.e. applications), then sell those applications (or utilization of those applications) and…and here’s the kicker…actually be compensated for their work. Imagine if you leveraged the freedom of OSS and at the same time appropriately compensated developers for their effort. Afterall, the value developers creates far exceeds that which an assembly line worker back in the 50’s contributed to the overall profits of a corporation—one developer has the potential to significantly contribute (or, conversely,  redact) from the bottom line. The problem with corporate software development, today, is that it is actually setup to discourage exactly the very kind of contributions which could have significant impact (where’s the incentive for the developer?)

“Rather than tie themselves down to a specific job with a specific company, instead developers will become software development consultants—bidding on projects, winning projects, and executing on them when they are hired by clients.”

Now for the Disruptive Part…
What’s most interesting is what happens when one considers the implications of a marketplace, as envisioned, above: software developers become, in effect, contract “mercenaries”. Rather than tie themselves down to a specific job with a specific company, instead developers will become software development consultants—bidding on projects, winning projects, and executing on them when they are hired by clients. Interestingly, this also has some nice side benefits: it allows the developers to sidestep the downward spiral of the “specialization” effect on their skill set, thus granting them a huge level of freedom (getting tired of working on back-end systems? Try your hand at GUI work, instead).  Developers can suddenly work on a diversity of projects, with a diversity of colleagues. Development teams would likely naturally form (as developers discovered other developers and team members that they like to work with), but nothing ties the developer to said team: they can decide at any point to take on an entirely new project with entirely new team members. This, in addition, broadens a developer’s professional network, exposing him/her to a much broader base of experiences as well as techniques—arguably making for a better developer in the end.

For the corporations, this actually works out too. Remember when we earlier talked about offshoring? In effect, should software development evolve along the lines stated, above, you’d have a kind of nullification of the offshoring effect: it’s not a matter of where it’s cheaper to house employees—it’s more a matter of who the best developers are—regardless of location. Sure, cost will still factor into the equation, but at least the playing field will be leveled in that companies will naturally value creative solutions which provide them the maximum of flexibility over the “cheap” solution. This means that a good developer—no matter if you’re Ukranian, Indian, Chinese, American, Spanish, or Dutch, would get the work. And for the corporation, it actually maximizes their efforts by most efficiently utilizing resources (read: money) spent on development efforts.

“…companies which fail to adapt to the new realities of software development will find themselves in danger of irrelevance. This new paradigm cuts out the middleman—and thus potentially could disrupt the entire software industry.”

In the end, it’s the application of marketplace economics on software development—something we’re already seeing in the form of marketplaces for web services (StrikeIron is a great example of this) and in componentized apps (widgets and mashups are another good example). If the market should move in that direction, it will pose an immediate and significant challenge to traditional software companies (IBM included): companies which fail to adapt to the new realities of software development will find themselves in danger of irrelevance. This new paradigm cuts out the middleman—and thus potentially could disrupt the entire software industry.

The benefits, however, far outweigh the potential negative consequences, assuming corporations are willing to adapt to the new realities. In essence, it’s nothing new, really: companies are forced to adapt to change constantly. The question is which companies will embrace this new model, and which will attempt to fight it? Answer that question, and you’ll know who will be the dominant players in the software industry ten years from now.

The Future of Software Development, Part I

// February 15th, 2008 // 1 Comment » // Emerging Tech

Why Software Development Is Going to Disrupt the Software Industry

Full disclosure: I am a former developer. It’s something that I feel should be stated upfront, because it provides some insight into my particular perspective when it comes to the current state of software development. And, yes, I also work for IBM.

Setting the Stage
I’ll begin with what is not news for your typical software developer, today: software developers are not being appropriately compensated for their efforts by the industry. In fact, in many ways, you could draw parallels between what developers are experiencing today and what exploited workers have experienced in the past—working conditions which served to oppress rather than encourage, wages which were out of alignment with the actual value that the worker is producing, widespread discontent in the worker ranks. These indicators, I believe, are pointing to a significant realignment of the market—and is setting up the market for a significant disruption—one which could have widespread implications for any company employing developers today.

So, why do I believe that such radical changes are brewing?  There are a number of factors coming into play—converging, really—which have the potential to seriously alter the landscape: the first is the continuous pressure on software companies to reduce costs to maintain their traditionally high gross margins. Second is the advent of the Software as a Service model, as well as the potential for the evolution of marketplaces servicing those technologies (see SaaS: Still another acronym for Software?). Thirdly, we have the adoption of the collaborative development model first proposed by Grady Booch back in 2002. It doesn’t take much to see that the convergence of these three factors has the potential to provide the seeds for a marketplace disruption—not in terms of new and evolving technologies, but how technologies are leveraged by those creating the products and services which rely on them. Think of it this way: the impact of robotics on the automotive industry has reduced the raw number of automotive workers from their peak membership in the 70’s (over 700,000 strong) to the current levels today (180,000) in the US. True, there were a number of factors influencing this dramatic decrease (including offshoring), however, we’ll see that those factors may also influence software development, and in a greater context, the software industry as a whole—not by constricting or reducing the number of developers, but by changing the game, and in essence, liberating those developers. It amounts to be, in the end, a kind of revolution.

The Evolution of Open Source
So, let’s set the stage by first looking at the open source model from the perspective of software developers: why do developers participate in something that, literally, gives them no tangible monetized benefits?  The answer is: most don’t. The typical evolutionary path for an OSS project goes from: initial idea -> gathering of like minded developers to realize the idea -> implementation of the idea -> market validation (or rejection) of idea -> If validation, eventual commercialization. The path, in other words, leads to some sort of monetized, commercialized, software. We’ve seen this happen with innumerable OSS projects, ranging from MySQL to TripWire to JBoss. The intent may have never been to commercialize the software, but the reality is that once these projects reach a certain critical mass, in order to sustain them, a business must be built which has the capabilities to provide that support—that in turn costs money.

“This is something the software industry, for the most part, still hasn’t figured out—and rather than leveraging these inherent talents, your typical software company simply creates a rather ugly hole, drops the developer into this chasm, and then expects the developer to happily create what amounts to be boring, isolated, and intellectually poisonous code.”

The Corporate Cube
Why am I discussing this? Because it goes to a deeper issue: software developers are creative. There’s a reason why developers talk about “elegant code”. There’s a reason why the best coders are viewed as much as artists as technologists. This is something the software industry, for the most part, still hasn’t figured out—and rather than leveraging these inherent talents, your typical software company simply creates a rather ugly hole, drops the developer into this chasm, and then expects the developer to happily create what amounts to be boring, isolated, and intellectually poisonous code. Why do you think “cube cities” are so despised by the developer? It’s a physical manifestation of what software companies do to the developer’s professional career.

“there’s been one significant barrier to OSS really disrupting the existing corporate software paradigm: it doesn’t pay. Literally and figuratively.”

OSS has succeeded to the extent that it has largely because it provides a necessary safety valve: it’s a channel by which the developer can break out of the “cube” of commercial software development, and actually exercise the skills and creativity that drove the developer to start writing code in the first place: it’s a kind of intellectual freedom. However, there’s been one significant barrier to OSS really disrupting the existing corporate software paradigm: it doesn’t pay. Literally and figuratively. Without the ability to put “food on the table”, the switching cost for a developer to move from commercial development (which he/she hates) to OSS development (which they obviously prefer given that the rewards are initially so minimal) are simply too high. It’s not just economically feasible.  The time is ripe for a solution—and I honestly believe it’s an inevitability rather than a pipe dream: this change will occur, it’s just a matter of when it happens.

All of which we’ll examine in my next post...