Engineering Values in IT

New Study by The Royal Academy of Engineering, The Institution of Engineering and Technology and the British Computer Society on the Advantages of Engineering Approach to IT Projects

2 min read
Engineering Values in IT

My colleague Martyn Thomas, informed me of a new and interesting study just published titled, "Engineering Values in IT."

The study was a joint effort of The Royal Academy of Engineering, the Institution of Engineering and Technology (IET) and the British Computer Society (BCS), and follows on to The Royal Academy of Engineering and BCS 2004 report, The Challenges of Complex IT Systems.

An underlying question motivating the study was, "What is the value of an engineering approach in the development of IT systems?"

The conclusion reached was that an engineering approach was indeed valuable and needed in IT, more so than ever given the central importance of IT to the successful functioning of society at large. Therefore, the study focused much of its attention on how greater professionalism could (and should) be brought to bear on the tasks of specifying, procuring or developing software-based IT systems.

As noted in the Royal Academy of Engineering  press release, the requirement for software-based IT systems to be reliable, robust and usable itself requires software developers to have significant technical skill, an engineering mindset, and a professional and ethical approach to the development of these systems.

In light of these needs, the study made a number of recommendations, two of which are key. The first is that IT professionals should work

"to achieve chartered status, the standard mark of professionalism and competence. Chartered status, either Chartered Engineer or Chartered IT Professional, requires a commitment to an institution’s code of conduct, and to continuing professional development, which involves the broadening and deepening of experience and maintaining an understanding of advances in the underlying science, changes in the legal and social environment and the development of new engineering tools and technology."

In addition,

"In order to stimulate uptake of chartered status, procurers of large IT systems in government and industry should employ chartered professionals to lead and manage these projects. This report recommends in particular that appropriate chartered status should be a requirement on leading engineers engaged in development of systems with implications for safety or national security."

The study notes that universities must supply the "push" by ensuring that their undergraduate education reflects the realities of engineering a large scale IT project, including the complexities of working with legacy systems and the associated challenges of change management, while industry and government must provide the "pull" by hiring accredited engineers to manage large-scale IT projects. Neither are sufficient in and of themselves, nor will they be necessarily easy to achieve.

The bottom-line of the study is the same as what I argued a few years back in IEEE Spectrum on why software fails:

"Like electricity, water, transportation, and other critical parts of our infrastructure, IT is fast becoming intrinsic to our daily existence. In a few decades, a large-scale IT failure will become more than just an expensive inconvenience: it will put our way of life at risk. In the absence of the kind of industry-wide changes that will mitigate software failures, how much of our future are we willing to gamble on these enormously costly and complex systems?

"We already know how to do software well. It may finally be time to act on what we know."

The study says in effect, let's get on with it already.

The report deserves to be widely circulated (and read) not only in the UK, but in the US as well.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less