In Part 1 of this blog series, I presented a rather dysfunctional conversation going on between software consultants and you, their client. I explained what consultants mean when they use the word “productivity,” why it gets convoluted, and how understanding this can lead you to making better choices for your company.
I originally promised that in Part 2 I would go into some specific software products. But I’ve decided to postpone that until Part 3, and first tackle another confusing topic.
Part 2: The Two Meanings of Scalability
Like “productivity,” “scalability” is a ubiquitous buzzword in the consulting world, and is also a pitfall for you.
1. Number of Users
For most web startups, the initial launch of the product would likely have a contained number of users: you, the friends you forced to help you test, and possibly some beta testers. Maybe you’re hoping to be in the tens of thousands in the few months after, with users visiting your site every day. Let’s call that “startup scale.” And perhaps the dream is to have hundreds of millions of users hitting your site constantly throughout the day. Let’s call that last one “Facebook scale.”
The shift from “startup scale” to “Facebook scale” can happen quickly, and you want to be sure that you choose the best technology for it. Refactoring your codebase later could prove fatally lengthy and costly.
Is your blood pressure up yet?
So, that was the scary story that will probably prompt you to constantly ask your consultant “But does it scale?” Your consultant, in turn, will walk the fine line of giving you the answer you want to hear while raising the scope and cost of the project, possibly even creating milestones along the way, ensuring an ongoing, gainful relationship.
My advice is to stop badgering your consultant about this.
The jump from “startup scale” to “Facebook scale” will be significant, no matter what your initial choice is. Companies handling each scale look very different: the former likely has a monthly hosting plan with a provider and spends a few thousand dollars a month for a few dedicated servers, bandwidth and tech support; the latter owns one or more “data centers,” huge facilities crammed with rows and rows of machines requiring constant maintenance at enormous costs. All this spells entirely different software architectures and priorities, requiring different kinds of technological expertise. In fact, you will likely need to hire new consultants when you get there.
It would be nice, of course, if there was one comprehensive technology that could easily take you all the way. Nothing quite like that is available on the market, but there might be, soon. Some of the big guys (notably Google, Facebook, LiveJournal) have embraced open source and the results are trickling out to us. Consider, for example, that Facebook recently created their own implementation of PHP that can significantly reduce costs for “Facebook scale” companies, while promising a smoother transition for those of us who choose PHP now.
The cost of adding too much “scalability” up front is a more complex product, harder to test and maintain. It inevitably involves data and content caching, one of the most difficult aspects, engineering-wise, of web development. Of course, software consultants make their money by developing software. They’d much rather create a complex caching solution than simply doubling the hardware to handle the extra load. But at the “startup scale,” adding hardware is a far, far cheaper solution. Importantly, it will also mean that you’ll be able to launch your product faster, and more quickly fix bugs and add features later. This aspect touches on the next meaning of “scalability” I tackle, that of managing your project, which ends up being far more important for you than number-of-users “scalability.”
On that note, don’t get too caught up in the “cloud computing” buzz when it comes to choosing software technology. “Cloud computing” is simply a new pricing plan for hosting. It’s a marketing invention, not a technological product per se, and all technologies can run on the cloud as well as they can on other hosts. One major caveat is Google App Engine, which is not compatible with all technologies. If you’re worried, ask your consultant about support for cloud computing, but don’t fret too much. It’s fashionable to run in the cloud, but it doesn’t provide you with any real technological advantage. Specifically, remember that “can run in the cloud” absolutely does not imply “scalable.”
So, how to avoid getting mired into this “scalability” discussion with your consultant? Make your priorities very clear up front: you want a straightforward system that can be scaled by adding hardware up to a minimum scale. Make it clear to your consultant that you know very well that refactoring will be needed when you reach “Facebook scale.”
Following the rule of thumb I suggested, be conservative. Ask your consultant for examples of other companies that use the suggested technology. Are they using the technology as is, or did they have to make modifications in order to scale? Luckily, there is a trend towards transparency and sharing wisdom among startups, and you can find a lot of important technological tips in their blogs. Blogs just like this one!
One caveat: do ask about minimum scale. Astoundingly, there are some software platforms out there that can’t even handle the basic “startup scale” as we defined here. This is most notable for CMSs (Content Management Systems). If you’ve read part 1, though, you should be immune to such arguments by now. CMSs are another case of those “productivity” products that end up costing you more and delivering less.
If you must, ask your consultant these questions: What database servers does the technology support? Does it support multiple database connections? Connection pooling? Replication (separation of reads and writes)? These features will guarantee the minimum “startup scale,” by letting you scale up – to a limit – simply by getting more hardware.
2. Project Scope
This is the kind of scalability about which you should be badgering your consultant.
In my article, “Making the Case for REST,” I define it as “the ability of your project to grow in complexity without degradation in your ability to manage it.” The choice of technology is critical. For example, in my article I argue that the main advantage of REST technology is exactly in how well it adapts to project growth by letting you use preexisting infrastructure. Conservatism, remember?
It’s important to point out that the issue is not project management. Obviously, a poorly managed project will fail. What you hope for, however, is that the project’s scope won’t grow beyond your capacity to manage it. Unfortunately, in the world of software engineering, that’s a very real risk.
Consider a common scope narrative for a startup. You begin with a very basic product that lets you play with a working model of your initial blueprint. It also lets you show off your ideas to investors, marketers, lawyers, etc. Lots of brainstorming follows, and major parts of the product are reworked. After more tweaking, a beta product is released for consumer testing. Here, you get some real-world feedback, and go back to the drawing board. Finally, you launch “1.0” of your product, and get criticism and suggestions from the blogosphere, press, enter into internet culture, foster a user community, and things change again…
That’s complicated stuff that has to be done fast. The world wide web requires the most condensed project cycles of any industry.
For this reason, it’s crucial to choose a technology that not only lets you create that basic demo quickly, but also lets your product move quickly into the next stages. Unfortunately, it’s not always in the consultant’s interests to put you on the right starting point. Instead, the consultant may prefer a technology that gives you the initial demo very quickly. At that milestone, you become very happy with your consultant’s quick results and are enmeshed in an ongoing relationship. Unfortunately, the next milestones will prove harder and harder to hit. At that point, it may be too expensive and difficult to switch consultants. You’re trapped, and possibly done for.
Once again, CMSs promise quick demos and poor scalability in this sense. Avoid them, and be suspicious of consultants that recommend them.
Badger your consultant about the technology’s ability to handle complex projects. Some questions to consider:
- Are there examples of complex sites out there using the technology? What was the experience of startups with it? Once again, check the blogs.
- Is the technology open sourced? Has it been around for a while? Does it have a generous culture of quality contributions? This allows for many common solutions that you can simply drop into your product later. If the technology is proprietary, what is the quality of its support?
- Does the technology play well with others? Does it support open protocols and standards? This would allow you to solve future problems with other technologies, instead of having to rewrite your entire product. A great platform to consider is the JVM (Java Virtual Machine). Technologies that run on the JVM gain instant access to a very wide range of technologies, and also let you switch the underlying operating system for even greater flexibility.
- Does the technology use common paradigms and established computer languages? If not, you will have a hard time finding and hiring programmers who can handle your project. As the project grows, this can become a major sore point.
And that’s it for Part 2. In Part 3, we’ll examine some technologies in detail. Java, PHP, Python, Ruby? Compiled vs. interpreted? MVC vs. REST? It’s going to be fun!
Design Done Better
The easiest way to get affordable, high-quality custom logos, print design, web design and naming for your business.Learn How to Grow Your Business With Beautiful Design