Smarter ideas worth writing about.

Choosing the Right Technologies for Your Project

So, once again, you’re starting a new project. It may be a project for a client, or it may be a personal project. Regardless, there are quite a few obstacles between you and finishing your project, and it is valuable to streamline this process. One major opportunity for improvement is the process of selecting your technology stack. It is one of the most important decisions you will have to make in the course of your project, and you have to make it right at the beginning, when you arguably have the least information. My goal for this article is to highlight what questions you should be concerned with when choosing these technologies, and in what order. While this isn't a “paint-by-the-numbers” guide that will spit out what technologies you should use for your individual project, this post will serve as a guide that will make the process of choosing technologies a bit less overwhelming. 

Identifying your project goals

The first thing you have to do is make clear the goals of your project, and write them down. Is it internal or customer-facing? If it’s customer-facing, is it for web, desktop, or mobile? Think of the key features it needs to support- does it need to be a “one-page” app (meaning you might want to use a JavaScript technology like AngularJS)? Do you need to support login/authentication, or single-sign-on for social media integration? These can be tricky and will likely be something you want to avoid implementing yourself by using technologies like Disqus or OpenID. In the case where your goals are specific, make a note of whether they are strict requirements or conveniences. Other goals to take into consideration are cost, performance, promotion, portfolio-building, or education. This list of goals can be as simple or as comprehensive as you want to make it, but I recommend a short list with a few goals ordered by priority. This should help you make judgment calls and any sacrifices you may need to make. 

Choosing the right development technologies

Once you are finished explicitly outlining your goals, you can begin selecting technologies. These fall into two major categories: your development technologies and the target deployment platform. These constrain each other, so I usually recommend selecting development technologies first, as they are more likely to be inflexible (at least if you’re working on a personal project). However, if you are working for a client that has an established deployment process, or if you are planning to make a mobile app, this decision might have already been made for you, and you will need to select from pre-approved or supported technologies. 

Determine whether you actually need a frontend, backend, and database. Obviously, any of these that you can eliminate (without compromising on your major goals) can dramatically decrease your project’s complexity and cost, both in the short term (up-front dev costs) and long term (hosting). Then, based on which of these you actually need, I would make a list of frontend, backend, and database technologies that your team knows or would be interested/willing to learn in the course of your project. Unless learning new technologies is the major goal of your project, I would try to keep unknown tech to a conservative level. Don’t try to learn a brand new frontend, backend, and database technology all in the same project. 

Examine how these technologies align with your goals. Obviously, if any of the must-have goals directly conflict with one of these technologies, it makes it easy to eliminate a few right away. Don’t get burned by fad technologies. There are developers whose goal is to learn the hip new language, whether for personal interest or to buff up their resume, but unless it has at least a few years of vetting, support, and compatibility, it’s probably not worth risking a major project on it. This applies to theoretically low-impact JavaScript plugins as well, to a lesser extent, although usually these are chosen later in the development lifecycle. I have been on teams that have lost weeks of developer time spinning their wheels on well-intentioned plugins. 

Choosing the right platform

By this point, your development technologies and languages should become pretty clear. Now it’s time to choose your deployment platform, assuming the decision hasn’t already been made for you. If the decision hasn’t been dictated, you are more likely to be working on something like an independent web project. This means you have to decide if you are going to host everything yourself, set it up on some webhost, or use a more comprehensive platform-as-a-service solution like AWS, Google App Engine, or Azure . This usually comes down to a personal preference between cheap/open and comprehensive/secure/easy. 

More and more, I am preferring these comprehensive PaaS solutions in pretty much all cases. Many of these services have free tiers that can host many apps almost entirely. Furthermore, they take care of a lot of the additional concerns for an application like security, scalability, cron jobs, and logging with easy-to-use interfaces accessible from anywhere, and many of these services will offer you their “content-delivery-network” which will deliver your app to users much faster than the alternative. Many developers may not want to spend their time implementing such things manually. 

The obvious trade-off is that you may find yourself spending time optimizing everything for that one host to minimize cost and meet any restrictions associated with that platform. Aside from potentially locking you into a host long-term, this can also eat up a decent chunk of time, which hurts the argument for using PaaS in the first place. Fortunately, optimizations designed to reduce cost in a PaaS, like eliminating unnecessary database queries and caching as much information as possible, is often best practice for customer experience and development in general, and your app will benefit in other ways from these optimizations.You also may be able to avoid lock-in with logical cloud management tools like OpenStack. 

When choosing between PaaS providers, you will want to look back at your preferred development technologies. Which of these providers supports most or all of your preferred technologies? Take special care to look at database support. Unfortunately, the deployment platform may occasionally trump your preferred development tech, and you may have to revisit it. An example of this is Google App Engine locking you into using their “Google Datastore”, rather than a conventional database. You may often find in these PaaS providers that, while it may be possible to customize to the technologies you want, it is often significantly more expensive. 

To make these judgment calls, look back at your prioritized list of goals. When this project is released, will it be put into the hands of someone less technically-capable than yourself, who may not be very good at digging through databases or logs? If so, you may want to opt towards a PaaS with a nice dashboard, like Google App Engine. Do you need logging or cron jobs? How secure does it need to be, and how capable is your team at establishing a secure application? What is the budget? An oft-overlooked factor is ease of deployment. It can be very nice to be able to deploy everything to your local, dev, or production environments all with simple one-line commands, and as it is smart to vet your individual technologies, it is similarly wise to vet your tech stack as a whole to make sure the individual technologies play nicely with each other. It also ensures that you will have end-to-end tutorials and support for similar full-stack projects available online. 

As developers, we usually want to get to the point in the project where we can compartmentalize and iterate as soon as possible. That can be difficult to do at the start of the project, so my goal was to subdivide the process into smaller, more digestible chunks. Hopefully, this post will help prevent major concerns and requirements from getting lost in the shuffle, or at least give developers a less overwhelming perspective on choosing their technologies.


About The Author

Software Engineer

Keith is a full-stack Java/Javascript software engineer and consultant for Cardinal's Columbus office.