Developing Production Software Faster

Reassessing your technology choices could be the first step toward driving innovation within your organization. By scrutinizing your existing tools and processes, you may discover a faster way to build and deploy software.

“Is there any way you can get it done faster?”

If you’ve ever worked on a software project, this question should sound familiar. You’ve spent time rewriting schedules, cutting features and explaining The Mythical Man-Month, the widely cited 1975 bible of software engineering. Its central principle is the slightly counterintuitive idea that adding manpower to a software project slows delivery.

This may make you wonder what will speed up projects. Consider examining your tools and processes to see if there’s a faster way of getting things done.

In his essay, Beating the Averages, venture capitalist Paul Graham addresses this reality. He argues that developers’ opinions of other languages are colored by their current language of choice. Anything closer to machine code is considered less powerful, and anything further abstracted from machine code is viewed as unnecessarily complex. Graham’s point is that we can’t really understand the “power continuum” unless we view it from the top. In order to choose the right tool for the job, it’s critical to possess a detailed understanding of the full range of options.

We can generally use this approach to question and validate our tech choices, with the goal of finding the toolkit that provides the best results in the least amount of time. So it’s important to determine whether your current technology choices meet your goals as well as other options might.

Faster tools

Consider version control, a seemingly bland topic, but one that affects almost every hour of development. Fifteen years ago, most systems used “pessimistic locking,” whereby only one coder could work on a file at any given time. With the advent of better tools for resolving conflicts between versions, “optimistic locking” became the new standard for version control. Multiple coders could then work simultaneously on their own copies of the same file — they just needed to reconcile their changes. Productivity increased as work could be parallelized. Conflicts diminished since people no longer needed to waste time chasing down the person who held the exclusive lock on a file, in order to check in their own work.

Fast-forward to today. Your developers are telling you to move from Subversion (SVN) to Git. But isn’t SVN good enough? The reality is that you won’t see the difference until you start using Git. Only then will you notice that:

  • Pushing or pulling code is faster
  • File merging is much easier
  • Commits are smaller and more frequent
  • Lightweight branches create a focus on features, not just milestones
  • You can version your own code locally without impacting the team
  • You can mentor developers faster and more effectively because you have a much more detailed view of their progress

In summary, you won’t see the benefits until you change your perspective. This is exactly what Graham was talking about.

Faster programming

Speeding up programming is one of the biggest challenges to advancing technology in most organizations. The assumption that you don’t need to learn y language because everyone already knows x is a risky one. Why? Because overnight x becomes outdated, discontinued or incompatible — or you can’t find anyone to work with it anymore. And where does that leave your business? You simply can’t afford not to re-train your people and embrace new technologies. As a leader, it’s your responsibility to continually identify and re-evaluate your choices in order to move your organization forward.

The Java 2 Platform, JEE and .NET were probably safe default choices a few years ago, but are they still? The developer coming out of school now might be partial to newer languages and frameworks that let them develop code faster in a more enjoyable way, such as Ruby on Rails, Django (Python), Grails (Groovy), or Play (Java). These modern Web frameworks are quickly becoming the de-facto choice for rapid development. They are created with a coherent worldview of what you need to get an application going quickly:

  • Simple, clean database layers, with reproducible migration scripts
  • Standardized, built-in testing tools
  • Capabilities to handle security issues like cross-site request forgery (CSRF) by default
  • Solid Model-View-Controller (MVC) completely integrated, allowing clear abstraction between business logic and view code
  • Built around newer Web standards like HTML5, REST and unobtrusive Javascript
  • Minimal configuration

There are thousands of libraries that can give these frameworks almost any feature you could think of — from geo-targeting to full text search, allowing you to benefit from the work of some of the most cutting-edge, large-scale new companies, like Twitter.

Faster execution

Now that we’ve covered development tools and languages, what about deployment? If you separate the two, you’re missing out on a lot of power, speed, simplicity and cost savings.

Last year’s Razorfish 5 explained why you need to embrace the cloud. If you’re dealing with hardware requisitions and configuration, you’re losing speed-to-market time, and likely spending too much money. You also probably have more layers of process and communication than you need.

In order to release your Web applications faster, do less — at least where systems are concerned. Do you need 100 servers to render custom movies from your users’ photo albums? With the cloud, simply click a few links and they’re up and running. Release them when you’re done, and stop paying. That kind of instant scale saves you the effort of buying, configuring, powering, cooling and finding physical space for all those servers.

In many cases, there’s an even faster way: platform as a service (PaaS). Vendors like Heroku (owned by, dotCloud, OpenShift and AppFog make it as simple as uploading your app and choosing how many servers you need.

In the cloud, you can configure additional functionality quickly and easily. Need to send mail from your app? A single command adds SendGrid or Mailgun. Want to monitor performance and identify code bottlenecks? A single command adds New Relic. Need SSL? Upload your certificate and never touch a configuration file. Pick your data store of choice. Memcache, video encoding, SMS text messaging, full text search, iOS push messages, message queues and more can be set up in seconds — instead of hours or days.

In this model, traditional operations roles — such as sysadmins, DBAs and network techs — fall away. You develop your applications with an understanding of how you’re going to deploy, and those capabilities drive design decisions. Database replication, failover and backups are handled for you. Mobile apps like Nezumi let you scale up and down with a push of a button on your phone. You’ll never again need to leave your laptop and mobile data card in your trunk when you go mountain biking.

On the surface, PaaS costs more than regular cloud hosting. In fact, in most cases you are paying more to run on the same underlying cloud that you could directly deploy to yourself. The cost savings can be more than made up for by the fact that almost everything you need is a click away. Heroku’s hostname SSL service costs $20/month. If an employee who costs you $50/hour took two hours to do the same configuration on a “pure cloud,” at a total cost of $100, you would need to run the app for more than five months to come out ahead.

This kind of calculation is fundamental to rapid application development. The general idea is that your recurring hosting costs may be a bit higher, but your personnel costs are much lower. If your $50/hour employee ($8000/month) became just 10 percent more productive, their value would increase by $800. This is what you need to weigh against your PaaS costs. You can lower both development and operational costs and get more done faster. And you reduce the chance of introducing errors.

We expect that five years from now, all new applications will be deployed to a PaaS platform. With the right capabilities available, there is no reason to be bothered with low-level details such as server configurations and software installs.

Faster overall

So are all these approaches right for every situation? No. There are valid business reasons to maintain or even build new proprietary deployments and to use pre-existing languages and frameworks. But it’s critical to constantly question standard practices in order to drive innovation.

The right choices are the ones that let you build applications that serve your customer better in less time and at a lower cost. By making the right tech decisions, the next time someone asks if the app can be built faster, the answer may be, “Yes, we are actually going faster every day.”

What techniques has your organization used to develop production software faster? Martin and Rafi would love to hear about them.

Written By

Martin Jacobs Group VP, Technology Twitter
Rafi Jacoby Technology Director, Social Twitter

Follow the Conversation

#rapiddev #R5v3