Two major issues that erode code quality in a company are
- unnecessary code duplication, and
- non-standard coding style.
To tackle these, I held meetings with my team to identify common functionalities that everyone expects (and often repeatedly re-implements) in their software modules. From these meetings, I gathered all these common functionalities as well as additional feature requests and made them the requirements for a new library I would implement.
The library I architected handled foundational aspects of flight software modules such as message passing between modules, tracking state in state machines, a common command interface to allow manipulation of the state machine, sensible diagnostic log messages, and an 'error' state to allow for root cause analysis of a software module's failure. The library does a great job of enacting the DRY (don't repeat yourself) principle. Each new software module to be written would be an object that inherits from this library's main class, and thus benefits from all the features without having to implement them again.
By creating this and explaining to the team the philosophy behind the library and how to best use it, I was able to create a coding culture/style that is consistent among all developers on our team. The mundane parts of the code became more robust and predictable, and this helped to prevent a lot of software bugs and errors. The team got engaged as stakeholders and helped me by further refining the library and adding needed features, without causing too much code-bloat/scope-creep. Code reviews became much easier too, because now we all write code in a similar way so we are familiar with the structure and can focus on the unique details of each implementation. Finally, the code is now completely modular as there are well-defined interfaces between modules, the controller and the receivers (GUIs). All of these contributed to a codebase that is of much higher quality than before.