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.
- Developing Production Software Faster
Is there any way you can get it done faster?
If youve ever worked on a software project, this question should sound familiar. Youve 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 theres 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. Grahams point is that we cant really understand the power continuum unless we view it from the top. In order to choose the right tool for the job, its 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 its important to determine whether your current technology choices meet your goals as well as other options might.
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 isnt SVN good enough? The reality is that you wont 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 wont see the benefits until you change your perspective. This is exactly what Graham was talking about.
Speeding up programming is one of the biggest challenges to advancing technology in most organizations. The assumption that you dont 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 cant find anyone to work with it anymore. And where does that leave your business? You simply cant afford not to re-train your people and embrace new technologies. As a leader, its 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
- 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.
Now that weve covered development tools and languages, what about deployment? If you separate the two, youre missing out on a lot of power, speed, simplicity and cost savings.
Last years Razorfish 5 explained why you need to embrace the cloud. If youre dealing with hardware requisitions and configuration, youre 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 theyre up and running. Release them when youre 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, theres an even faster way: platform as a service (PaaS). Vendors like Heroku (owned by salesforce.com), 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 youre 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. Youll 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. Herokus 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.
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 its 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.