Developer Friction

What Is Developer Friction?

Developer friction is any part of the software creation process that prevents the programmer from easily and quickly building their code. With software taking an increasingly important role in automotive development as the industry works towards Connected Autonomous Shared Electric (CASE) Software-Defined Vehicles, developer friction can negatively impact the delivery of new products and features. Modern automakers’ customers crave new and delightful capabilities, many of which come from software, so easing the delivery process is essential.

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 Auto, 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

A development process hindered by delays contrasts with the trend toward continuous development. Software coding has enlisted agile processes for years, but continuous deployment takes this further. In a traditional development methodology, even an agile one, when a developer commits code, it may not be tested with other modules for days or weeks as it waits for the rest of a build to be completed. With continuous deployment, committed code goes straight into the current build and is immediately included in testing. That way, bugs are caught straight away, and the code can be reverted until the bugs are fixed. The result is a faster route to production software releases to customers.
The QNX® Hypervisor is a real-time, Type 1 hypervisor that offers virtualization technology and enables the secure separation of multiple operating environments on a single SoC. QNX Hypervisor brings containers to connected automobiles as a way to segment non-safety applications from critical systems.

Check Out Our Other Ultimate Guides

Structural Dependency
Learn about software-defined vehicles, including their benefits and architecture.
READ THE GUIDE
Structural Dependency
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
READ THE GUIDE
Structural Dependency
Learn how cloud computing for automotive works and its benefits.
Read the Guide
Structural Dependency
Defines autonomous systems and the various levels of autonomy
Read the Guide