Hey, you made it to part 4 of my series on all the steps that are involved when creating a software application. If this happens to be the first one you’re reading, make sure to head over to the previous parts linked below:
Part 1 - The spec
Part 2 - Making mocks
Part 3 - Data, Schema and Storage
I bet some of you are thinking...
Just show us some code already!
...but how can I show you code if we haven’t even decided what programming language to use? In today’s post we’ll go through some of the ways in which we decide what technologies to choose to use in our apps.
The factors to consider
Let’s first take a moment to consider what factors are at play when deciding what tech we’re going to be leveraging in order to create our next app. These factors are probably true of many other decisions we make both in technical fields and out.
1. What is our end goal
The first thing to consider is what is it that we’re actually trying to achieve with building this app. What we eventually choose will be different if we want to build a business around this app versus if we want to learn how a specific technology works. In the case of the app we’ll be focusing on throughout this series, the end goal is to serve as a reference that I can show to a potential employer. I discussed the details thereof in the final part of my previous series: “Why I’m switching to Angular”.
2. How much time do we have
In pretty much every endeavour that we take on in a professional setting, there are going to be deadlines. Sometimes even in non-professional settings (read: coding for fun) we’re going to place some time-limit on ourselves. When deciding what tech to incorporate we have to keep in mind the limits that are placed on the project.
3. How much can we spend?
The last thing I want to mention before moving on is that we always have to consider what the costs are going to be of our project. It’s important to think ahead of time how much we are willing and able to spend in order to get this project completed. And I don’t just necessarily mean monetary costs - although that is very important to consider as well. We have to look at what potential opportunity costs there could be. What I mean by that is we should also consider what it could cost us to do this project instead of another project. It’s usually better to work on something of value than it is to develop another version of snake.
Steps to select the right tool for the job
So now that we know where we’re going and what our limitations are, let’s get into how we select which tech to use when developing our app, finding the right tool for the job at hand.
1. Figure out what you need
This kind of fits in with keeping in mind what you’re trying to achieve. The best place to start would obviously be… as with every other step in the process… the spec you developed in part 1 of the series. Hopefully your spec is written clear enough that you can extract the different components required. If it’s not that clear, then you can use this list of three basic components of almost every app.
- Interface - this includes more than just a GUI or HTML, API’s and text interfaces are still ways in which you can interface with your app.
- Logic and processing - Essentially what programming language are you going to use and which frameworks and libraries do you have to include in your project
- Storage - very closely related to part 3 of this series, but it boils down to how are you going to store the data that your app uses. This is usually done with (but not limited to) a database of some kind.
2. See what’s out there
Getting an exhaustive list every possible technology in existence in order to find the best one is kind-of absurd, but it’s still a good idea to at least look at a few options that you could use.
3. What are other’s using
Part of your research into what tech is available should also include trying to figure out what the “industry standard” is. If a lot of people are choosing one technology over another it’s usually for a good reason, it will pay off to at least find out what that reason is. Another benefit of going with the popular option is that there’s usually more help available should you get stuck. It’s also easier to find someone to hire that’s familiar with the more popular tech.
4. What are you more familiar with
This step is highly reliant on the things to consider mentioned above. If one of your goals is to try and learn more about a specific technology, then obviously you’re not going to know it all that well, but it would be a good idea to use as many familiar parts as possible to ensure you don’t try to cram too much information into your head as possible. Also, if your app has a pretty tight schedule to completion, it won’t help to choose everything that you have to learn from scratch to use. If you’re going to be working in a team, it’s also important to consider the expertise of everyone involved.
5. Which is the simplest solution
Finally, you have to try and estimate which of the different technologies will be the least amount of work to help you get to where you’re going. The simplest solution is almost always the best solution. But keep in mind what you’re end goal is. The simplest solution for development is not necessarily the simplest solution for scaling. For example getting a MySQL database on a shared hosting provider is comparatively easier than setting up a large Hadoop cluster running highly tuned load balancers, but if you have a billion records to sift through, your puny little MySQL instance is going to be very difficult to maintain and kept running. On the other hand, if you’re app is only going to be used by a dozen or so users once every 3 months - or even just by yourself - then an SQLite database running on a Raspberry Pi in your basement could be sufficient.
The tech I’m going to use for the Web-Resume app
So, in case you were interested in knowing what I’ve decided the best tech would be for the example app I’m using throughout this series, here goes:
- Angular for the user interface (I wrote about this in an entire series of posts, here, here and here)
- Because I’m using Angular I’m also kind-of forced to program using Typescript, which is a good thing generally.
- For storage I’m going to try and keep it as simple as I can, which would be to store everything on a local file, i.e. no database. This is kind-of just for the beginning stages of the app, if it turns out that a lot of people other than myself wants to use it as well, I might switch over to MongoDB or Firebase.
- I’ll be hosting the app on good old Github Pages. I’ve had a pretty good experience with Netlify in the past - one of my previous apps was a crossword puzzle generator which I host there - but for this project I think having a user clone the project to their github account and add a single JSON file with their specific details will be good enough for now. If I happen to get some growing demand for this app I’ll revisit this strategy.
Pretty simple setup I’d say. Hope you enjoyed this post, hopefully next time I can share some code bits…
But I’m not making any promises yet...
