SolDevelo created a fully open-source transportation system for Digital Impact Alliance. In this case study you will learn what challenges we faced, what methodology and technology we have applied, and what results were achieved with this project.

Our Client

Digital Impact Alliance (DIAL) is an organization that focuses on increasing access to digital solutions, and on supporting digital transformation around the world. They use their resources to contribute to achieving the Sustainable Development Goals (SDGs) by 2030.

DIAL’s mission is to provide equitable access to life-enabling services and sustainable development digital tools for all global communities. They believe that everyone, everywhere should have the opportunity to use the essential services they need to thrive. To make it possible, DIAL engages in many initiatives aiming at increasing accessibility of technologies.

The project that we worked on with DIAL aligns with their mission. We were asked to rewrite the TransIT system to be fully open sourced and, in result, more accessible.

The Challenge

DIAL needed a tool that would solve the problem of the lack of visibility into the supply chain, particularly in low-resource and challenging last-mile environments. Although transportation management systems are capable of dealing with this issue by tracking where shipments are at any given time, whether they have been delivered, and costs at each stage, many commercial solutions are too expensive or not flexible enough for diverse and low-resource environments.

DIAL requested a system that would be providing data and resources to support management over supply chains as well as have reporting features. It was important for the client that the system be easily accessible and serve as a Global Good. 

Therefore, we built the solution based on an already existing system, but using the newest technology and making sure that it is fully open sourced. The challenge was to build a tool that would enable managers to better track shipments, make data-driven decisions, optimize distribution resources and assets, and use historical data to show trends over time. We have also worked on redesigning the system so that the user experience is improved.

The Solution

Methodology and Technology

Even before the development work began, we conducted research into how to optimally carry out the project in the best way possible. We looked at both the technological solutions and the working methodology. The key characteristics of the project that had an impact on the decision were:

• Building a solution from scratch based on a legacy application used in a production environment.
• Entirely open-source nature of the new application.
  

It was also important to transfer functionalities while improving them as much as possible (but remain in the spirit of the already created solution).

Due to the relatively short duration of the project (3 months) and the roadmap being planned for the entire duration – the choice of a Scrum with 2-week sprints was a no-brainer. This allowed us to monitor on an ongoing basis how our progress matches to the initial assumptions – roadmap, estimates, etc. The biggest advantage was that we could continuously consider making changes suggested by stakeholders, as well as reacting in a timely manner when progress diverged from the original assumptions. Or, in the spirit of Agile, change the original assumptions and respond to change with an updated plan.

The choice of technology was a little more complicated. The number of available programming languages, frameworks and libraries is huge. When starting a project from scratch, the responsibility lies with us to select a solution tailored to the specific situation. From a developer’s perspective, it is tempting to choose a cutting edge tech stack, which we have recently experienced and which seems to fit our project perfectly. 

On the other hand, however, especially in the case of open-source solutions, we want the project to take on a life of its own, attract community interest and have a relatively low entry threshold. With this mindset in mind, we chose Python and TypeScript, which may not be revolutionary, but are still up-to-date and popular.

Python is in charge of the server side – Django and the Django Rest Framework are mature, proven solutions with a rich tech ecosystem. In addition, the application places a strong emphasis on providing statistical data in the form of metrics or reports (both embedded and delivered via a separate, integrated BI application). Python is one of the leading languages in the context of data analysis, so we were able to make use of libraries such as pandas, without any additional expansion of the technology stack. If it becomes necessary to implement a neural network in the next phases – we are prepared for that, too. 

In the same vein, we made the decision to have the front-end part written in ReactJS. According to the Stack Overflow survey React is one of the most loved and wanted web frameworks. We believe that proven efficient solutions with strong community support are the best choice.

Quality of tech solution

The choice of technology alone (unfortunately) does not determine the success of a project, it is also important that the team delivers a solution that is of quality. The most important factor is the people that are involved in the process. The development team had already had the opportunity to work on projects where the aforementioned technologies were used. 

The involvement of the Enabling Team was also of great help. They shared knowledge gained in other projects, provided support in fields of expertise in which other team members were not super proficient, and allowed a vigorous start of the development. 

The first step after creating the repositories and initiating the projects was to add CI and CD tools. We wanted to know immediately what impact the new changes would have on the code base. Using GitHub Workflows, Tox, SonarCloud and other tools provides us with measurable information about what is the quality of our code. Everytime changes are made from the beginning of the project lifecycle, we monitor, among other things:

• Is the solution building correctly?
• What is the code coverage?  
• Do all tests pass?
• Are there any critical bugs that could affect security?
• Does the code adhere to our predefined requirements for static code analysis – Flake8 for the backend, Airbnb’s ESLint for the frontend?
• What cyclomatic and cognitive complexity do we have, is the complexity of new classes within a reasonable range?

In the spirit of transparency, all quality statistics are publicly available: SonarCloud TransIT Backend. Readability, Maintainability and Security metrics are currently A-rated. At the moment it is not a huge challenge to achieve this level, as the backend has <10k LOC (we probably could go from D rate to A rate in a single sprint), the important part is that we keep this level of quality during the whole development process. 

Additionally, for the time being, code coverage is ~95%. This does not mean that the code is completely bug-free, but gives us a good indicator of how changes in existing code will affect existing functionality. Early in development we introduced a generic base for testing endpoints Manual Inputs. While most of the time those are basic CRUD operations, they are the cornerstone of the application. Adding this early on in the process, allows us to create tests for further Manual Inputs, while at the same time reducing the amount of resources that we will have to allocate to write tests. Similar approach was applied to the tests created for the built-in reports. 

Additionally, we created test data factories. Those could be helpful when the application grows and further developers might want to use in tests more complex objects that they do not necessarily have the knowledge of. We strive to keep quality in the project approachable. One of the most noticeable advantages of this approach is that when frontend developers request any changes in logic or structure of the provided API – those changes can be smoothly implemented without spending excessive time on testing. It would be a lie to say that all corner cases were predicted in advance and covered by the tests. From time to time we still have to make some fixing, however there was no situation in which code change would unexpectedly break anything.  

Stumbles on the way

Majority of the work on the project went smoothly. However, we faced some minor challenges that arose on an ongoing basis – e.g. inconsistencies in task estimation in the initial phase of the project, or different understandings of how certain things should work when communicating frontend to backend. These were mainly due to the fact that the new team needed time to get in sync. If the team has problems coming to an agreement, the reasons may include a lack of transparency, communication problems or a lack of understanding of the project goals. In the case of this project, this was certainly not a thing. 

Of the more serious obstacles we faced, two could be mentioned: integration with an external mobile app and the choice of BI tool.

In the case of integration with a mobile application – this was an aspect of system migration that was not given enough emphasis during the initial research and requirements gathering. We found out about it around the second sprint and it was difficult to create the space for another big feature with an already existing plan (while not changing the priority of other deliverables). In addition, the code for this application itself was delivered late in the project. Consequently, it was not possible to deliver this functionality. This kind of situation can be unpleasant and demotivating. 

On the one hand, it is not a feature that we were obliged to deliver when we planned our work before the project started. Therefore, we are planning to work on the integration with a mobile app in the second phase of the project. An additional downside is that we have spent time gathering requirements, doing research, planning and familiarizing ourselves with this external application. This knowledge will carry over to the second phase of the project, however, the time spent on this could have been used more effectively on the key functionalities for the first phase. 

Lessons learned 

By thinking about what could be improved in the future – we could be more decisive about the throw-ins mentioned above. It does not mean rejecting requests for a change that have arisen after work has started, but rather reacting to changes and putting customer collaboration over contract negotiation. However, finding out early enough whether a given change can replace another element in terms of priorities would be really helpful.

The Result

We managed to finish the project on time and within the given budget. We created a new system from scratch, using the newest technology and making sure that the quality is on a high level and tech debt is reduced from the very beginning, making a great base for further development of the system. 

The whole system is refreshed as we prepared all the new designs, new logo and also built and implemented a website for the project. Now TransIT is fully open sourced so it can be considered a Global Good fulfilling Sustainable Development Goals.

Download Case Study (PDF)

About us

SolDevelo is a dynamic software development and information technology outsourcing company focused on delivering high-quality software and innovative solutions. An experienced team of developers, customer-oriented service, and a passion for creating the highest quality products using the latest technology are the undeniable advantages of the company.

ISO 9001 confirms our dedication to the highest quality and ISO 27001 shows that we treat security extremely seriously. Over 70% of our team members are certified Scrum Professionals, over 35% are Oracle Certified Professionals and 100% of our quality assurance team has ISTQB certificates.

If you’re interested in our work, we invite you to read our other case studies.