At this point I assume you’ve read Part 1 and Part 2. You’re fairly well acquainted with what coding is and why we do it. You even understand the basics of design and delivery. Now, we’re going talk about branching in software, source control, deployments, and more.
Before we dive in, I wanted to give a special shoutout to our sponsor of this post, Pramp! If you didn’t know this already, Pramp is a quickly growing interview site designed to help you ace the technical interview. When you join Pramp, you get unlimited, free, technical interviews with your peers where you answer real questions used in job interviews. Check ’em out!
When we have input, we want to branch so that the output depends on the value of our input.
For example, if you’re less than 13, you don’t get access. If you’re greater than or equal to 13, then yes you get access.
This will only print the age if the age is greater than 12. You can see that we essentially branched our program based on the input. As we code more, our programs become more complex.
Every single execution is not going to do the same thing once we start branching our software. This is known as dynamic aapplication development.
This is in contrast to, say, old websites that display the same thing every time you visit the page. These websites are not dynamic. The content of the webpages are hardcoded in HTML. A dynamic website is when you are able to sign in and get a welcome message like “Welcome, Caleb! Here are 5 things that might interest you.”
This changes depending on who is signed in and what that person’s interests are. This is a great example of a dynamic application, but in reality nearly all applications need to be dynamic. This essentially means that there needs to be more than one output.
In the example above we got the input from user input. We are not going to always want to do this. Rather, we can get this information from a database, a text file, config file, or anything of a similar nature.
These files allow us to make our program dynamic without having to ask the user numerous questions every time they open the application. In the above code example, the application would ask the user’s age every time they ran this piece of code (which would happen at least once every time the application is executed). With a config file or database, we can store their birthdate, retrieve it using code, and either give them access or not without asking the user anything.
This also means that if something isn’t working right, a tech support person can modify the configuration file and see if the application works now. This allows us to give one code copy / deployment to the customer, and then we can just change a couple little things to make the app work in different ways. Anytime you can put something in a database or configuration file rather than hard coding, that is what you want to do.
Scalability with Agile
The question now is how do we get from a few lines of code to a huge codebase with tons of users? We need to scale and grow our application. One of the challenges is organization and deciding what to build and what not to build. This is because applications are actually really hard to build (not just saying that because I’m bad at it).
We need a framework to think about building applications. One of the most common frameworks is known as agile. The way agile works is we take our application and break it up into user stories (cards). Every piece that needs to have some functionality, we write this down as a user story. This is essentially writing down the user is going to interact with your application. This is very similar to a requirements document.
A requirements document is essentially the agreement when you sell an application to a company. We are going to build a custom application, here is what you say you need and what you are paying for. Agile takes a requirements document and formulates it into something more actionable with bite size pieces.
We then have sprints. Sprints are usually two week long segments where we agree to a certain amount of work. At the beginning of each sprint, we decide what user stories / cards we are going to focus on for those two weeks. At the end of every two weeks, we should have a completely functional product. Even if it’s just a very small product. This is not a product we would deploy to our customers.
All I’m saying is that our progress should come to mini completion in that it’s functional, any new features are completed, and minimal bugs exist. Even though the application may be simple, it still works. Then every sprint, we essentially add features until we reach the MVP (minimum viable product).
Why an MVP? Essentially, we want to build the absolute minimum required for application to be complete. Not to be lazy (I don’t buy into the whole you should be lazy thing). You want to build the minimum required because that’s what was agreed to, it reduces bugs, and makes simpler software. This allows us to get product out the door faster and add capabilities rather than putting off deployment over and over and over again forever (it happens).
When developing, we may have a local deployment server for testing or a sever that mimics the customer’s environment. This allows us to get a sense of what the application will be like once we deliver the final product to the customer. It also allows the customer to “check in” every now in again to make sure actual progress is being made.
When developing locally (like on your laptop for example), you’ll likely write code and eventually deploy it to the test server mentioned earlier. This, in a sense, is you saying that your code is complete and it should be ready to be tested against the requirements document.
There are multiple types of software testing. The most common is automated testing, which consists of unit tests and integration tests. We also have manual testing, where a person goes through the requirements document and verifies that the application is working from a user’s perspective. If you have a large enough team, you may have a person or a team dedicated to testing, but often times you’ll be the one required to do the testing for your code, both automated and manual.
Source Code VS Executable
When I first started developing, I had confusion on what was actually delivered to the customer. Do we give them source code or a compiled version of the source code (known as an executable)?
It depends on who the customer is. If we are working as a software development consulting company, we are likely creating software for another company to be the complete owner of. They can edit it, sell it, whatever! In this situation, you would give them everything.
The other option is if we are creating software for customers to use. In this situation, the source code remains our own, and we simply deploy an executable.
What if we are developing apps for our own company to own and for the world to consume? This changes the development process because we are no longer bound to requirements by an external customer. Instead, these requirements are defined by an internal customer. If you are a software engineer at a company, you’ll likely have key stakeholders or people you can consider your clients. In this situation, the development and deployment process stays basically the same.
Source code, as we’ve talked about, is the code written to develop an app. When working in teams (or even by yourself), source code can easily become unwieldy. For example, how can multiple people work on the same code when there is potential for conflicting changes? The solution is to store all of your code in a centralized repository using a source control management system such as Git or Subversion. This concept is known source control.
GitHub is a popular website that allows you to store you to centralize your code to one location. By this I mean we are essentially giving our code a home. This repository is the source of truth and contains the most up to date, official code.
GitHub can be used for open source projects completely free. This means that you make the code publicly available for anyone to see and use. In contrast, a project can be closed source, where the code is hidden from consumers and it’s only possible for users to get a deployment of the software (an executable), and not the source code itself.
If you’ve read up to this point, you have a pretty good foundation. There’s still a lot to learn when it comes to software deployment. I’d recommend you read this book (The Agile Samurai). I read it and it was tremendously helpful for understanding the software delivery process.
I’d also look into other delivery patterns. For example, read about continuous delivery for software as a service (SaaS).
Please let me know what you thought. What are / were your biggest challenges as a new developer?