Software development cycle for dummies
A quick walkthrough of how lines of code are turned into a product
On a daily basis, we see a lot of texts and materials talking about how to improve processes, studies about it.
But do people really understand how an idea turns into lines of code that become a product? Well, my idea here is to go through the most important points of this process and explain how it all happens.
The aim is not to go over technical points or the tools or frameworks that are commonly used in these processes. By the end of this text, I want you to understand how the overall logic of software development works.
Let's go?
Getting started
It all starts with the business team getting together to outline what needs to be built. At this stage, we define the solution in business terms. Information can emerge from user feedback, specific product requirements or even a newly signed contract. It is at this point that we decide what will be done. For example, we might decide that we're going to develop a website that allows users to share photos with each other. That's our basic premise.
With this initial vision, the product and engineering teams break down the big idea into smaller tasks or user stories. To materialize our website, for example, we'll need to establish the infrastructure, develop the APIs, design the user interface and so on.
These tasks are then prioritized during planning meetings, which are held according to the dynamics of each team. Some organizations choose to hold these meetings weekly, while others prefer a fortnightly interval - it all depends on the company's culture and leadership.
Development
Once the work has been planned and prioritized, the developers start building. For larger initiatives, there is usually a design process to align the architecture to be followed and the technique we will have for the problem.
At this point, the developers start writing the code and use Git for version control and create branches of features to develop new functionalities without affecting the main code base. This way, several people can work in parallel and their code will be merged with the original so that it talks well together.
Code review
Once the code is ready, the developers open a pull request for the team to review. This process helps to identify problems early on and improve the approach used by the developer who worked on it. Problems such as inserting bugs or interrupting what might be working can be avoided in this review phase
After approval, the code is merged into the branch with the main code. At this point, what we call Continuous Integration/Continuous Delivery (CI/CD) pipelines are triggered after the merge.
These pipelines will take this code and make it available for the user or team members to test in a development environment and then in production.
Validation
Once the functionalities have been implemented, an equally important phase comes into play: testing. Here, the quality of the software is put to the test, and any flaws are identified and corrected.
Testing can be manual or automated and ranges from unit checks of small components to integration tests that evaluate the system as a whole.
This assesses whether no side effects have been caused and whether the implementation meets the acceptance criteria. Does information flow as it should? Has the user's need been solved? Did the bug no longer occur?
Release
Finally, once the tests have been passed, the software is ready to be delivered to users. However, the work doesn't end there. Ongoing maintenance is vital to ensure that the system remains up-to-date, secure and aligned with the constantly evolving needs of users.
It involves validation of features by the product team, QA and developers. Release candidates that pass UAT move slowly into production, sometimes using techniques such as canary releases or feature flags.
Monitoring
After the release, there is the phase where the changes are followed up and monitored by the team.
Here we can also take a rollback approach. Rollback is an operation that returns the code and database to some previous state. In these cases, if something we've built has gone wrong, we can return the user to the way things were before and the operations take place again while the problem is adjusted.
Throughout the process, engineers monitor metrics and logs for any production problems. Product teams also monitor analytics to ensure that the feature works as expected and positively affects the company's objectives.
Conclusion
By following this flow of software development, we can see the complexity and importance of each stage for the success of the project. From the conception of the idea to post-launch monitoring, each step requires care, collaboration and attention to detail.
Understanding this process not only gives us a clearer view of how things work behind the scenes, but also enables us to contribute more meaningfully to software development.
I hope I've helped you.