What Is Developer Friction?
Causes of Developer Friction
There can be many causes of developer friction, from organizational to the choice of technology platform.
- Development team members might not be annotating their code adequately so that others working on the code understand how function calls fit together.
- The platform itself could need more documentation.
- The QA department could be too intrusive in the process, requiring lengthy checks of every new piece of code.
- An automotive software product could rely on various platforms that conflict and require excessive bug testing to interoperate smoothly.
- Cutting-edge innovation may have yet to adequately define requirements towards which developers can work.
- There may be a lack of standards for a product area, such as autonomous driving.
- Undiscovered bugs due to insufficient use of Software in the Loop and Hardware in the Loop testing could cause a roadblock in the release schedule.
How to Reduce Developer Friction
One of the most effective ways to reduce developer friction is to build code on a platform that removes many systems-based hindrances. A platform with broad support for third-party environments will mean that interoperability will come as standard, and developers won’t need to build this themselves. For example, BlackBerry QNX supports Android Automotive OS (AAOS), enabling applications to be integrated alongside other automotive systems more easily.
Beyond this, using an appropriate and fully featured Integrated Development Environment (IDE) for each development area will pay dividends. When building code for an automotive Real-Time Operating System, an IDE specifically focused on the ECUs being used will smooth the process considerably. Some IDEs will even compile code automatically when the source file is saved.
Developers increasingly use cloud-based DevOps systems, enabling physically distributed teams working on code to collaborate more effectively. This is essential with automotive products that bring together elements from a range of stakeholders, including third-party suppliers.
Waiting for new code to be tested on a real hardware platform, such as a prototype car, can severely slow development. By employing Software in the Loop testing to assess initial designs, followed by Hardware in the Loop testing for later builds, a lot of friction can be removed from the process.
Benefits of Reducing Developer Friction
Increasingly, software provides features that attract customers to an automotive brand rather than physical design. The less friction in developing these features, the better they will be and the faster they will be delivered. This can have a very positive effect on a brand’s appeal.
If the software development process is frustrating, that is likely to create additional opportunities for bugs to be introduced and not ironed out before release. Conversely, a lubricated development process will mean bugs are fixed quickly and updates rolled out rapidly, perhaps via an Over the Air system. Not only can this save money due to not needing a physical vehicle recall, but it will also please owners when a software niggle is rapidly removed.
Developer Friction Vs. Continuous Deployment
Check Out Our Other Ultimate Guides
