Development 2.0

I never think of the future – it comes soon enough.

Undoubtedly, Mr Einstein advice is quite prescient, especially if you look at the IT industry today– the future is here, baby! We are already in a new era that is largely defined by two key aspects that are rapidly changing the character of development for those keen organizations already leveraging them. Indeed, to abuse the platitudinous “2.0″ theme, Development 2.0 is largely defined by:

• capitalizing on open source technologies
  • that is, fully leveraging open source technologies across the board from application servers, databases, and core frameworks of a solution
• borrowing infrastructures
  • that is, renting (or borrowing) all levels of applications required for managing and running software applications

Neither aspect is new nor revolutionary; however, both make a lot of sense when you look at the value that each provides together from the standpoint of a business. That is, these tenets enable organizations to deliver software faster, cheaper, and better. All of which speak to the long-lived frustrations of businesses around the globe.

Development, like a lot of things in life, can be divided into two aspects — strategy and tactics — or simply: what is done (strategy) versus how something is done (tactics). Both aspects are important and both play off of each other — one must know what to do before one figures out how to do it. In this case, Development 2.0 largely focuses on the how (or the tactical aspects) of development. It should be noted that from a strategic standpoint, the process aspect of Development 2.0 has already been established: it’s Agile. While Agile processes are no silver bullet, the principles they espouse have demonstrated they work (i.e. deliver results) time and time again.

Yet, Agile projects can still fail if they aren’t tactically aligned with success; thus, the how aspect of Development 2.0 addresses the prime frustration businesses have with IT: speed. All other frustrations are related and can be traced back to this single desire. If an IT organization could deliver working features when the business snapped its fingers, the argument of cost would never arise. What’s more, businesses assume quality. It’s only when quality can’t be perceived that it becomes a complaint.

Thus, for a hip IT organization to deliver real value to a business, it must deliver working features in a timely manner. And to do so, organizations must write fewer lines of code and spend less time managing developmental infrastructures. By leveraging open source technologies, IT organizations can spend precious time on businesses issues (and not technology issues that have already been largely solved in the open source arena — that is, object-relational mapping, testing, monitoring, etc); additionally, borrowing another entity’s platform (such as Google’s App Engine or Amazon’s EC2) means less time is required to manage development infrastructures (machines, networks, scalability, security, etc) . Furthermore, these two tactics have the added benefit of lowering the cost of development! It’s a veritable double whammy of benefits — the speed at which features can be delivered is increased while the overall cost of those features can be decreased.

Can you dig it, man?