We build web and mobile applications, and we’ve been doing so for a little over fifteen years. To our delight, technology has evolved and improved in many ways over that time.Technology evolution can be cyclical, with some branches looping back to the past with surprising vigor and without much self-awareness. Platforms eschew threading and then re-invent threading anew. Client-side code is passé and then the client becomes the preferred runtime environment.

As software developers, we’re technophiles, so we enjoy these cycles and quite often find humor listening to the energy spent arguing on either side of issues. It’s a fun and funny business to be in.

Through our fifteen years, we’ve been charged with helping clients get business done with technology. Focusing on the metrics that ultimately drive the business, often the bottom line, has provided a reality check, a counter-weight to the desire to consume all new technologies. Over time, we’ve imbibed that reality check serum, and now it’s part of our instinctual technical point of view.

We love technology, but…

Sure we still get excited and animated about a new JavaScript library, a new CSS trick, a new device, or a new data store. We’ve learned to think about how this really fits with the business needs of our clients. Is putting this hot new technology to use on a client project for our technical interest or is it for their business interest? Does it help our clients sell more widgets or deliver with fewer headaches? Or do we want to play with this new toy simply because playing with new stuff is fun?

Not to downplay developer happiness. It’s important to us. But a newly minted developer given access to Hacker News can develop ADD in a week’s time, waste countless hours reading the opinions of professional and amateur technology opinion-makers, and nervously fidget about selecting the hippest framework and libraries to (briefly) avoid the scorn of hacker pop culture.

Anyone who has been around the web development block is going to tell you that they select technologies with some balance between coolness and pragmatism. The web development continuum has sound, safe, but stodgy on one side and shiny-obsession at the risk of unknown stability on the other. Few developers will find themselves at an extreme or precisely in the middle, and we’re no exception.

Our business model nudges us slightly toward the sound, safe (stodgy?) side. We work with clients to get them off the ground with a platform to build their business. As the technical partner, we want to be real partners in the business-making sure the technology helps achieve the business objectives. Incurring additional risk based on jumping on the latest and greatest technology is most often not the best route. Our clients want us to make it safe to innovate. They have enough worries.

Skewing us toward pragmatism is a combination of factors:

  • Our clients are not about technology; they are about running their business using technology. So even if that business doesn’t exist as anything but a web site, we want them to avoid unnecessary technology risks.
  • Although we spend plenty of time researching and developing with new technologies based on desire and need, we don’t want our clients to be guinea pigs (unless that’s the nature of their business, of course).
  • We want our clients’ business to be supported by technology that is fast, lightweight, and pain-free to administrate.

Easy stuff should be easy

We cut our teeth building eharmony.com back when a server with 128MB of memory was a monster. This gives us a point of view about servers and modern web application development that isn’t terribly common these days: each server in your cluster should be able to process a significant amount of user load. On modern hardware, a trivial dynamic request should run as close to 0 milliseconds of server-side processing as possible; and it is unacceptable for a request to take 200+ milliseconds unless it’s doing some heavy lifting.

After all, napkin math tells us that if requests take 200 milliseconds, only five requests per second would saturate a processor core. Those requests had better be worth it!

A site with a million users is much easier to manage today than it was in 2000. Today, a million users should not require dozens of servers unless the business is by its nature compute-heavy.

As with premature optimization, premature scaling is probably unnecessary and may be harmful. Most importantly, you don’t necessarily know if you’re scaling in the right direction. On the other hand it’s silly to dogmatically avoid simple patterns that reap the easiest initial salve for scale: processing requests quickly.

Imagine your prototyping is over, and you’re building a production system. You’re in the thick of it and about to write a small chunk of server-side code. You estimate it will take 5 minutes to implement a clean but low-performance implementation; 7 minutes to implement clean and quickly-executing code; and 8 hours to do it optimally.

Which do you choose? We generally go for the 7-minute option. Perhaps it seems a no-brainer in this context, but you’d be surprised how many people choose the 5-minute option because it appears to save money. Yes, making the same decision several hundreds of times throughout a project adds up to measurable additional time. But our experience is that routinely selecting the “7-minute” option pays off in the long run.

Caveat: with web application development, your foundation technology choices determine if you’re going with the “5-minute” approach to everything or the “7-minute” approach to everything. You can’t mix and match.

With respect to software testing, most developers acknowledge that finding and resolving a defect before integration tests saves time and effort. It takes a bit more time for each developer, but it saves the effort of reporting, tracking, and dealing with bugs that leak beyond the developer’s sieve. Curiously, the same sense doesn’t necessarily apply to tuning and platform selection.

For production systems, we contend it’s often better to select a platform that saves you money in the long run even if it means a few more dollars spent up-front.

Think of the money!

Money plays a big part in this. Allow me to be brutally clear: the more our clients’ budgets go to Amazon or Rackspace, the less budget goes to continued development time. Development time is how we earn money. Besides, more development time means the client can be more agile with functionality and has a greater potential for success. So it’s not an entirely selfish position.

Hosting is a necessary cost, but if you find yourself spinning up a second server when you have only a few hundred users, you might ask yourself why a CPU capable of processing billions of operations per second is brought to its knees by a few users submitting forms, placing orders, and communicating with one another.

Amazon is more than happy to accommodate you if you’re not interested in asking this question. Jeff Bezos loves web application inefficiency.

Mixing technologies for a project can feel like concocting the right blend of chemicals. Some work well together and other clash. Project needs vary, of course, so technology chemistries vary in turn. Barring important indicators, our default assumptions steer us toward a mixture that aims to provide breathing room for scale together with a platform for reasonably quick evolution by the development team.

However, a severe budget limitation may tip toward a platform with ready-to-use open source components that can be leveraged as-is or with minimal tweaks. A need to on-board an in-house development team composed of recent college graduates (tempered with an understanding of performance and scale economics) pushes for Ruby/Rails, ensuring a talent pool from which to select.

Playing it safe

Building technology for non-technical clients pressures us to be mindful of that unknown future team. By comparison, an in-house development team starting a project may follow a more daring technology trajectory established by the technical director, especially if the director has a bunch of cohorts he or she can bring on board.

The clients we support often do not have an in-house team and must be prepared to eventually source that in-house team from the client’s regional talent pool. This eventual hand-off to another team, in whole or in part, means that even if a client has a desire to dabble in new technologies, we still prefer to select those that have credible momentum and widespread usage. Vanilla node.js, MongoDB, Cassandra, and Apache Cordova for example. But we’re not going to put a client on Meteor.js or MySQL’s new NoSQL-like cluster. At least not yet. Similarly, we’re not going to build key components on a platform for which it can be difficult or exceptionally expensive to source developers, such as Scala, unless the other project variables conspire accordingly.

Technology evolves and the number of people voicing their opinions keeps growing (welcome to this blog, by the way!) but getting work done requires shutting down the news feed and writing code. When working with other people’s money to implement their ideas, we don’t want to be technology early adopters. We’ll satisfy those cravings after-hours.