Onboarding a new developer on a traditional software team is cumbersome, time consuming, and in many cases requires help from existing team members. It often takes weeks or months for a developer to become truly productive and stop being a drain on the rest of the team. This is especially noticeable when joining a product team where the responsibility is only for a component or subsystem in the product.
Let’s take a look at some of the current onboarding steps for a developer working on a full stack web application.
- Understand Product Architecture – The first thing every developer wants to see is the system architecture of the product. Typically the architecture diagrams are slide decks or README files on the Wiki or some shared location. Very soon they realize the architectural diagram is out of date due to no one updating it as the product was being developed and maintained. So, they end up talking to different people on the team to truly learn what the architecture should look like.
- Experience Working System – Having seen the architecture, every developer wants to see the product working end to end. This would mean installing the different components and environment settings. For a typical full stack application this may include the web server, application server, and the database server. Again, there can be different database flavors, versions of web servers, etc. Going through installing each of these on the developers machine or a virtual machine may or may not be the developer’s skill set.
This whole education process can take a few weeks or more based on the product complexity and even then, there will continue to be questions and things lost in translation as this information resides in various team members heads.
Monolith vs Microservice
Most architectures are monolithic, making them hard to visualize and understand. A new architectural pattern called microservice architecture is emerging to address this problem by decomposing applications into micro-services leveraging Docker containers to run these micro-services. The entire application can be deployed from a docker-compose.yml file.
Within a matter of minutes, the entire working system is available within the web server, application server, and database server as containers. With the working system in place, the developer can see the entire application working end-to-end. Now, he can work on his component and test the entire system before releasing. This whole cycle is very fast.
While moving to a microservice architecture is a great step to understand the components of an app, there is still a gap in visualizing the relationships between the services. This gives the developer a whole working system, but visualizing the product architecture is still a challenge. Yipee.io is a great visual modeling tool that solves this problem. You can import an existing compose file and visualize the entire application, allowing you to visualize image dependencies, networks, and volumes.
Interested in learning more about Yipee.io? Sign up for free to see how Yipee.io can help your team streamline their development process.