Yousef Eddin

File manipulation and dataset management. Our primary dataset came from a university in Brazil, the UFPR-ALPR dataset, and contained thousands of annotated vehicle images. Wrangling that into a usable format for training and evaluation was a significant effort in its own right, involving custom scripts to reformat annotations into YOLO-compatible bounding boxes and reorganize the directory structure entirely.

Building a production API. The distortion engine, PlateShapez, is a fully packaged Python library with a CLI, a Python API, configuration file support, and a plugin-style perturbation registry. I used Processing (PDE) early in the project to prototype the shape-drawing logic, then migrated the full system to Python with a proper architecture. The API supports reproducible generation via random seeds, dry-run previews, and structured JSON metadata for every generated image.

Code standardization with UV. I used UV to manage dependencies and enforce a consistent development environment. The project has a full CI pipeline on GitHub Actions, pre-commit hooks, Ruff for formatting and linting, and mypy for type checking. The goal was to build something a stranger could clone, run, and trust, not just something that worked on my machine.

NEAT as an optimization backbone. Rather than hand-tuning perturbation parameters, we used NeuroEvolution of Augmenting Topologies (NEAT) as an optimization strategy, evolving configurations over multiple generations using evasion rate as the fitness signal. This let the system discover non-obvious parameter combinations that a manual sweep would likely miss.

The technical execution wasn't the problem. The problem was that two people built essentially the entire project. Myself and one other teammate were genuinely invested, we understood the problem, cared about the outcome, and drove everything forward. The rest of the group never got there. The work was too far outside their comfort zone. They were used to loading a CSV, running a model, and calling it done. Building a synthetic dataset pipeline from scratch, implementing a custom perturbation framework, training a YOLO detector, that's a different category of effort, and we never successfully brought them into it.

To be fair, we tried. We built out a shared checklist and assigned work explicitly. But a checklist doesn't manufacture engagement, and it doesn't replace the hours of context-building that made the project make sense to us but not to them. Work concentrated on two people. The presentation suffered because the people presenting it didn't fully understand what they were presenting.

To address this, I believe that I should be focusing more on project management skills, specifically Lean. Lean project management isn't just about efficiency, it's about eliminating waste, and the biggest source of waste on a team isn't bad code, it's misalignment. When people don't understand why something matters, they disengage. When they disengage, the work concentrates on fewer shoulders. And when the work concentrates, quality suffers in the places you're not looking. In our case, that showed up on the presentation stage, not in the codebase.

If I could go back, I'd spend the first week differently. Less time architecting the pipeline, more time getting everyone to feel the problem. Show the team a Flock camera mounted on a telephone pole. Pull up a map of how many are operating in your city. Make it real. Because once someone understands that a network of cameras can reconstruct your daily routine from your license plate alone, the synthetic dataset stops feeling abstract and starts feeling necessary.

That's the Lean principle I underestimated: shared understanding as a prerequisite to shared effort. You can't pull people into unfamiliar territory with a task list. You need a story they care about first.