IBM

Second Year Project — Software Development in Large Teams

Student Developer

Period
Location
Copenhagen, Denmark

Collaborated with IBM as part of ITU’s Software Development in Large Teams project, developing an MVP for an open-source platform that helps companies calculate CO₂ emissions from transportation through a working API.


Overview

As part of ITU’s Second Year Project: Software Development in Large Teams, I worked on a software project in collaboration with IBM. The goal was to build an MVP for an open-source solution that could help companies understand the environmental impact of their transportation activities.

Our team developed a web-based solution centred around calculating CO₂ emissions from transportation. Rather than only presenting information about sustainability, the project provided a working API through which transportation data could be processed and translated into estimated emissions.

My role

I worked as a Student Developer within a larger development team. Unlike smaller university projects, the focus was not only on implementing software but also on learning how a larger team organises, coordinates and delivers a shared product.

My work involved contributing to the development of the MVP while participating in the team’s Scrum process, collaborating with other developers and helping turn the requirements of an external industry partner into a working software solution.

The problem

Companies increasingly need to understand the environmental impact associated with transporting goods and operating transportation networks. Turning transportation activity into a meaningful CO₂ estimate, however, requires a consistent way of processing the underlying data and performing the calculation.

The project explored how this process could be exposed through an accessible, open-source solution so that organisations could calculate transportation-related emissions without having to build the underlying functionality themselves.

The solution

Together with the team, I contributed to an MVP that allowed transportation information to be translated into estimated CO₂ emissions. A working API formed an important part of the solution, providing a programmatic interface for performing the calculations.

The intention was to make the solution openly available and provide companies with a free starting point for incorporating transportation-emission calculations into their own workflows and applications.

  • Calculate estimated CO₂ emissions associated with transportation
  • Expose emission calculations through a working API
  • Provide a web-based interface around the underlying functionality
  • Develop the solution as an MVP that could be iterated on
  • Keep the project open-source and accessible to organisations
From transportation data to CO₂ estimate

A conceptual view of how the platform turns transportation information into an emissions result.

  1. Transportation data

    Transportation information is provided to the platform as the input for an emission calculation.

  2. API request

    The data is submitted through the API in a structured format.

  3. Emission calculation

    The system processes the transportation information and calculates the corresponding estimated CO₂ emissions.

  4. CO₂ result

    The calculated emission estimate is returned so it can be presented or consumed by another application.

Working in a large development team

A major part of the project was learning how software development changes when many developers contribute to the same product. Features could not be developed completely in isolation: interfaces, requirements and implementation decisions had to be coordinated across the team.

This gave me practical experience with collaborative development beyond simply dividing a project into independent tasks. Changes needed to fit into a shared codebase and a shared understanding of what the product was supposed to become.

Agile development with Scrum

The team organised the project using Scrum, working iteratively rather than attempting to design and implement the entire system upfront. Development was divided into smaller pieces of work that could be discussed, implemented and evaluated throughout the project.

Working this way gave me practical experience with agile software development and showed how regular communication, prioritisation and incremental delivery help coordinate a larger engineering team.

Collaboration with IBM

Working with IBM added an industry-facing dimension to the project. Instead of developing solely from an academic specification, the team also had to communicate with an external partner and translate project goals into concrete software requirements.

That experience helped bridge the gap between university software projects and professional development, particularly around communication, requirements and delivering something that another stakeholder could actually evaluate and use.


What I am responsible for

  • Contributing to the development of a transportation CO₂-emission calculation platform in collaboration with IBM
  • Developing functionality for the project’s MVP
  • Contributing to a working API for transportation-emission calculations
  • Working collaboratively within a larger software development team
  • Participating in Scrum and iterative development processes
  • Translating project requirements into working software
  • Collaborating with an external industry partner throughout the project

Engineering challenges

  • Coordinating development across a larger team where individual changes had to integrate into a shared product.
  • Turning the broad goal of calculating transportation-related CO₂ emissions into concrete software functionality.
  • Balancing technical implementation with requirements and feedback from an external industry partner.
  • Keeping development coordinated through iterative Scrum processes rather than treating the project as a collection of independent tasks.

What I learned

  • Building software in a larger team requires communication and coordination just as much as technical implementation.
  • Breaking a product into smaller iterative deliveries makes complex projects easier to coordinate and evaluate.
  • Working with an external partner taught me how requirements evolve through communication rather than arriving as a complete specification.
  • APIs provide a useful boundary between domain-specific calculations and the applications that want to consume them.
  • The project gave me practical experience applying Scrum and agile development beyond smaller university assignments.