In the current tech scene, it has become common practice to refer to programmers as engineers. It seems that if you aren't part of sales or marketing teams you are now entitled to being designated as an engineer. However, what has been forgotten over the 50 years of looking to turn software development into a legitimate engineering practice, is that we still haven't reached the aspiration of being just that: a legitimate engineering practice. Traditional engineers have to go through stringent regulation, certification, and apprenticeships in order to gain the title. This creates an implicit responsibility of providing reliability and public safety. Software development hasn't reached this point yet - software quality and standards are not universally valued.
So why is the tech industry using the engineering title to describe its technical workers?
There have been many headline grabbing failures in the software industry that point to the shortcomings of the industry in reaching the status of the engineering discipline (just look to the failures this summer at the New York Stock Exchange, United Airlines, and the Wall Street Journal). However memorable these events have been (and plentiful), they also reveal an acceptance of failures that would never be accepted in more concrete structures that require the expertise of the traditional engineer. We may not see software as being as important as the security of buildings or bridges, but computing has become inherent to many infrastructures. Software is now used in cars, elevators, and even healthcare equipment -and it's not being held to the same standards as other modes of infrastructure.
When it comes to the infrastructure of skyscrapers, bridges, and power plants engineering is managed by professional standards and the regulation. It seems that the use of the term 'engineer' in the software industry is similar to greenwashing in heavy industry (in order to appear environmentally responsible), and pink-washing in the consumer industry (in order to reap the rewards of cause marketing). The tech industry is leveraging a history of engineering accountability and responsibility to public service in order to create the appearance of trustworthy products.
Since the 1960s the prospect of making software development closer to the engineering approach has been an ambition. However, the democratization of software development (due to the rise of the personal computer) incited a consumer and business software revolution; effectively changing the stakes of software engineering. Products like a spreadsheet or reservation program still have to work like a bridge or building, in other words, requiring the engineering approach. Other cases, like a modern app store don't require that type of discipline.
Adding to the informality of software development was the rise of the web. As software moved to the websites, smartphones, and the Cloud, two important changes occurred.
- The pressure to get things done right the first time around was removed. Updates and changes can now be applied centrally. This gave rise to the use of rapid development, since the ease of repair is assumed.
- Software has become isolated. Previously, software had to work with other systems: an automobile customer-management system would have work with dealers, suppliers, shippers, etc. This is not the case of today - look at a product like Instagram where the photos uploaded and shared only go between its servers and the app.
What has happened in the current software development industry, is that although these Cloud services still rely on infrastructure, they have been outsourced and have become black boxes to individual developers. Software development has become sealed off and opaque - this is the opposite of what the engineering discipline is supposed to be.
Engineering is meant to be a collaboration at the service of a public - traditionally, engineering has been a civic practice. This means that they bear a responsibility to the public, which in turn pushes them to create products that engender trust. Engineering is also a discipline where accreditation and degrees are still valued. Silicon Valley companies are moving away from such requirements. And development practices like Agile and Scrum move even further away from these type of static requirements. Software has become focused on temporary results (rapid-iterations are more prevalent than long-term planning).
Given the nature of software development as it stands today, it doesn't make sense to keep calling developers and programmers 'engineers'. Maybe the occurrence of more data breaches and software failures will cause the public to ask more of the software industry. However, at the moment, the software development industry does not hold itself to the standards of other engineers where the burden of servicing the public renders projects that hold up against the test of time.
To read the original article, 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.