Cars are no longer simple pieces of machinery, but have evolved into highly integrated pieces of technology - with software embedded into all their critical systems. In 2017 4 out of 5 cars will be connected to the internet. Reliance in software will bring new challenges for automobile makers as the technology used for infotainment and safety critical systems require different levels require different standards of quality. If your dvd player in your car stops working there are different repercussions than if your emergency brake stops working.
For example, by 2021 the U.S. National Highway Traffic Safety Administration (NHTSA) and U.S. automakers have agreed to implement automatic emergency braking in most vehicles. The braking systems rely on the technologies within the cars cameras, proximity sensors, and radars - all which need to function without error in order for these emergency brakes to function themselves. The camera that was previously used as a optional assistance in parking will now be integrated into a safety critical element of a car.
This brings about the issue of software quality in legacy code. Most applications are built off of existing legacy code. Considering the effort and resources that went into building this existing code, organizations will try to leverage as much of it as possible when building something new. The issue with reusing legacy code bases is that they are often riddled with technical debt. Accumulated technical debt causes issues with the maintenance of the software and its overall quality.
The key to reducing technical debt is to refactor - but it is something that causes a lot of anxiety amongst developers as refactoring once piece of code can affect the functionality of another piece. Once of the biggest hurdles to refactoring legacy properly is a lack of proper testing (which is often a source of technical debt to begin with). Without proper testing it is almost impossible to tell whether any refactoring will cause regression in an application's functionality or lead to some sort of technical failure. Lack of testing means that an application cannot be modified or maintained with ease.
You can begin to see how this will cause problems for new safety critical systems in cars - systems that are being built off existing software applications that were most likely not built with modifications like these in mind (i.e. built with technical debt). As software technology becomes embedded into more and more aspects of consumer products - and into critical parts of its functioning it will be necessary to find a way to address and alleviate the technical debt that is inevitably present in legacy code.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.