When you are starting a new software project, one of the first things you do is choose how to build it. Luckily for you, the software development world is rich with choices. You will have options of programming languages, databases, and much more. If you take a cursory glance at the features of several related technologies, they will likely look as though they can meet all your needs. Because of this, it can be challenging to decide what software to use for your project.
If you have struggled with this in the past or are currently struggling, here are some helpful questions to ask when trying to decide on what technology is right for your project.
Things to consider when choosing technology for your project:
1. What does your project need?
Before deciding what technology to use, you need to know your business and software requirements. First ask: what is your project or goal? Is it a new website, a mobile application, or an API (application programming interface) for public consumption? Ask what kind of data are you going to be gathering & storing, and what type of interface do you have to provide users? The list of possible questions is massive, and unique dependent on your specific company needs.
After collecting all your requirements, you can begin finding technologies to build your project. It is easier to rule out or include something in your project when having the ability to compare the technology’s capabilities against a list of what you need it to do.
2. What do you know?
The second step is what to consider after you have got your requirements and have identified a few choices of potential technology. It is possible you or someone on your team has worked on something similar in the past or has experience with one of your prospective technologies. It may make sense for your project to leverage that expertise as you are building the project instead of learning something entirely new.
Consider your company’s current "technology stack" or the tools used to build and run your software products. If your company has standardized on specific technologies, it could be in your best interest to utilize them as much as possible. This will make it easier for other developers to join your team and get up to speed as fast as possible. It also means that if you are out sick, on vacation, and something breaks, that you can rely on someone else to handle issues. If you are the only one who understands the project, you are the only one who can fix any breakages.
There are also many reasons you would want to use something new. Maybe nobody on your team has relevant experience, or perhaps your company’s "technology stack" is unsuitable for this project. Even if you are the only person they are going to call; you will have to put your nose to the grindstone and do the research, regardless of old or modern technology to find a solution meeting the specified requirements. There is no other way to make an informed choice on what to use.
3. What kind of support do you get with the technology you are considering?
The last thing to consider is the support behind your technology. If you are using something new, you will undoubtedly run into issues as you learn how to use it. If the latest technology has an active community, it is useful to "feel out" the community, determining whether they are helpful and friendly. If there isn’t a community, is the documentation good enough to meet your needs? Is it possible to purchase a dedicated support agreement for it? It is vital to determine whom to ask for help before you commit to using a specific technology.
You will also get an idea of how long a technology is going to last by answering these questions. A good, healthy community is a useful indicator of a technology’s longevity. Pay attention to who else is using it; enterprise adoption will mean that updates to the technology will continue for a long time.
Through answering these questions, you have hopefully narrowed down your options to the point where choice is transparent or at least less overwhelming than when you started. A final note is that market forces will make your project successful, not its architecture. Your customers do not care that you have perfected their software architecture. They only care that it works for them. If your technology choices do not lessen the customer experience, you have made the right decision.
Written by Ian Miller | Principal Software Developer