icm2re logo. icm2:re (I Changed My Mind Reviewing Everything) is an 

ongoing web column  by Brunella Longo

This column deals with some aspects of change management processes experienced almost in any industry impacted by the digital revolution: how to select, create, gather, manage, interpret, share data and information either because of internal and usually incremental scope - such learning, educational and re-engineering processes - or because of external forces, like mergers and acquisitions, restructuring goals, new regulations or disruptive technologies.

The title - I Changed My Mind Reviewing Everything - is a tribute to authors and scientists from different disciplinary fields that have illuminated my understanding of intentional change and decision making processes during the last thirty years, explaining how we think - or how we think about the way we think. The logo is a bit of a divertissement, from the latin divertere that means turn in separate ways.


Chronological Index | Subject Index

Leap before you look

A preliminary look at how we design the ways that make the will

How to cite this article?
Longo, Brunella (2018). Leap before you look. A preliminary look at how we design the ways that make the will. icm2re [I Changed my Mind Reviewing Everything ISSN 2059-688X (Print)], 7.5 (May).

How to cite this article?
Longo, Brunella (2018). Leap before you look. A preliminary look at how we design the ways that make the will. icm2re [I Changed my Mind Reviewing Everything ISSN 2059-688X (Print)], 7.5 (May).

The confusion between two diverse human activities - inventing stories and following traces in order to find something - is the origin of the incomprehension and distrust of science shown by a significant part of our contemporary culture. The separation is a subtle one: the antelope hunted at dawn is not so far from the antelope deity in that night’s storytelling.
Carlo Rovelli

London, 4 September 2018 - Seven brief lessons on physics by Carlo Rovelli is one of the most remarkable recent examples of successful science translation.

In less than sixty pages the author presents the status of his discipline in plain english and with a style that Italo Calvino would have possibly considered an example of leggerezza, that magistral levitas (lightness) of telling people complex concepts as they were just simple observations about the weather forecasts.

Rovelli subtracts all the unnecessary weight from language but not its function (by the way, Calvino’s Six memos for the next millennium is another little masterpiece in the cross-disciplinary art of writing ‘what’s what’ that Rovelli’s prose echoes in every sense, the other Calvino’s keywords being quickness, exactitude, visibility, multiplicity and consistency).

Then the seventh lesson comes, in closing: its title, Ourselves, puts the reader back in his seat, as Rovelli reminds us the limits and the fog that weights our universal scientific understanding of the world, starting from ourselves and our own role in the big picture.

Music to my ears. I have always been very fond of that reflective, lifesaver, practitioner approach to communication of scientific and technological knowledge: as a rutilant innovator I have always pushed my skills over the limits of my formal qualifications and current understanding of the world. As a Librarian, as an ICT Technician, as an Information Manager or IT Project Manager and Management Consultant I have often felt that I had just been catapulted into the uncomfortable role of a system engineer, with the moral and technical imperative of writing almost impossible requirements and designing magic solutions.

Will the development of data design practices mark the final affirmation of systems and data engineers? Let’s have a preliminary look at what such socio-technical change could mean.

Does designing the ways create the will?

Few months ago I have looked into the stories of two examples provided by two colleagues, both engineers, who have had similar disappointing experiences while trying to get a grip of some requirements from their clients as a way to agree and obtain some work contracts involving Quick Response (QR) Code technology they both assumed would be an easy-going and welcomed technology.

In fact, from the perspective of history of computing and technological innovations of our times, the life cycle of QR codes is exemplar. It took less than ten years from its first usage in vehicle manufacturing to come to an international standard concerning its very internal characteristics and structure (the construction of the symbols of the black and white squares). That was good enough to sustain a second wave of still pioneering commercial exploitation of QR codes in advertising and consumer electronics.

The second version of the ISO/IEC 18004 specification, released in 2015, unleashed a further third generation of QR applications in phone applications, e-commerce and banking and financial services that are now quite successfully - especially in Japan, China, India, and in several African countries. Here the QR codes are nowadays used even for smartphone payments. Of course, such developments have not paid any special attention to the problem of information security and financial frauds, counterfeit products (with authentic! QRs) or false links and associations, nor to the problem of trademarks and copyright infringiments - but these are other aspects of the rapid affirmation of QRs codes that are not immediately relevant for our story.

So, my two colleagues both tried to reuse the considerable experience they accumulated in recent years with the application of QRs codes and cloud based IT services.

But something went wrong. They did not get any commission and they both concluded that this was because their clients had no will to go ahead with the project as they had initially envisaged, in spite of the fact they were on average quite familiar with QRs codes. Who is not these days? QRs codes are everywhere.

What’s in a raindrop?

The information which one physical system has about another has nothing mental or subjective about it: it’s only the connection that physics determines between the state of something and the state of something else.
Carlo Rovelli

I was not very surprised to hear their stories by the way. The world goes in the direction of either modelling wannabe intelligent applications or coding bespoke solutions with “instant requirements”. Many experienced professionals struggle to align with such trends, as well as end-users do. They do not realise how little attention people tend to give to the representations of the objects or processes they want. And nobody seems around to remind that distinction between the antelope hunted at dawn and the antelope deity in that night’s storytelling.

Few fields I have been practiced for a while have been disrupted by the global digital economy as such as requirements engineering. And yet we do not see too much of such dynamics and reality reflected in formal best practices and academic literature. The handbooks and professional standards keep saying that the first purpose in life for a system engineer is, indeed, to remind the world there is a difference between the reality and its representations by a multiplicity of clients and stakeholders. How true! But are we ready to tell such truth to the world?

Luke is a Chemical Engineer but he has been actually professionally involved as a software developer and project manager for over 25 years. He was employed in the IT services division of a large multinational until the 2008 financial crisis. This caused his firm to go into a deep reorganisation during which he opted for a generous early retirement offer. Since then, he has worked as a consultant and freelance DevOps engineer, leveraging on a wide network of very good and trusted relationships with former clients and colleagues. He is very busy at all times but as per his own admission he would be in trouble if he could not count on his wife’s salary to pay the bills and the mortgage being his own earnings very irregular. Most of the projects he is constantly engaged with are either not for profit or they simply do not go beyond the valley of death of experimentation and academic engagement. After of couple of years of talks about IT developments for local authorities and schools, he has eventually the opportunity to translate one of his business ideas into reality within his own community, writing the software that would allow the integration of different services used by children, schools and families, mostly funded and supervised by the local authority. There will be no need for them to authenticate themselves multiple times per day on different systems, and this seems to be one of the advantages of Luke’s idea. Luke imagined to bridge different and disconnected systems through QR codes so that each family and each individual in the local community could enjoy a sort of virtual single sign-on across the platforms of different providers. At the same time, their personal data and actions would become traceable and transparently accessible by all the different organisations and third parties or suppliers contracted by the local authority.

Matthew’s case is quite similar. He is an Electrical Engineer who has recently started his own business too, incentivised by the opportunity to explore new fields of development and at the same time having some work assured every month. In fact, he keeps on working for his former employer’s main clients on a contract for services basis and within a tight but not incompatible non disclosure and not concurrent agreement contract, whilst he is considering alternative sources of income. As somebody who has been in charge of a small automation unit with a medium sized innovative company for the last twenty years, Matthew is very confident in QR codes technology that he has used in several occasions while designing and implementing robotic solutions for manufacturing and writing code for PLC units. Since he would like to widen his range of projects and work in other sectors and industries, he has put forward a proposal for a quite modest but decisive innovation to his local secondary school too. As in Luke case, his idea has gone completely ignored.

They both have not had any feedback at all from their potential clients.

I asked both who they had managed to engage with, to consult or work with in their communities in respect of the creation of data or generation of the QR codes as this activity would be of no complexity at all for them from a technical point of view but it is a relevant one from a political and governance perspective, being at the core of quite complex legal and social workflows each organisation involved would or should be responsible for. Above all, in both cases, the generation of the QRs would touch, impact or collide with the definition of roles and responsibilities, data protection obligations, retention schedule, quality control, access definition and more.

Put it in these terms, Luke and Matthew idea of using QR technology looks much complex than it seemed at first: it looks like they should design a system! And that is absolutely true. In a nutshell, a QR code is like the raindrop telling there are clouds in the sky and it has the possibility to enable, disable or impact innumerable other conditions and states. So there should be in place a policy for the creation and sharing of the QRs codes that should be obtained through the definition of requirements: that policy would be at the heart of a system designed for some agreed purposes, containing of course the tecnical application or software needed to manage the exchange of QRs codes among various platforms.

As I anticipated, both Luke and Matthew concluded there was no will to proceed. They would not have the budget nor the convenience to further investigate the raindrop connections or how to design the ways for the will to emerge.

Conclusions

Design and development of software products is not anymore what it was used to be when I first approached the discipline about thirty years ago: it was very predictable at that time. At that time there were no international standards, no great debates about policy or requirements aspects that were, however, recognised as preliminary and necessary for the development and implementation of good technological solutions to problems much more than they are today.

Today computer and data scientists tend to talk about coding as it was an alternative to poetry or knitting, wishing everybody to speak coding languages, promoting coding festivals for women and kids and projecting a popular, attracting idea of software programming as a field of individual expression. That is all right. All digital artists and users are welcome to a virtual world where they can theoretically give birth to their own creations and forms of expressions, just manipulating languages and sensed or shared data. They have most of the times no need to agree with others their reflections about the way they represent a problem, solution, an object, the world. It is a fantastic way to approach software production, but it is unfortunately not very useful in terms of what society and the economy need from engineers and from information and communication technologies.

We need instead to think about the representations of the world through digital technologies and the way in which we generate them.

I will return in another occasion on what such change means from the perspective of the requirements engineering specialist in an age of increased instant creativity.

For now, let’s just conclude that from the world of services and consumer electronics, the call for innovation of mindsets, methods and tools for requirements engineering have been flooding the industrial sectors too, without convincing postulates about how we have to design ways that create wills, and if we really need to.

Perhaps we all have to get acquainted with the idea that we need to leap first and then have a look at what is going on and invent how to improve it, using pre-defined sets of available code?

Nobody is seriously thinking that to have improved efficiency and more intelligent systems we need to go back to a world of requirements managed manually and bespoke proprietary software code, with interminable lists of bullets points manuscripts on a piece of scrap paper to start with.

But I confess sometimes I would rather see such U-Turn because, as Rovelli says in his seventh lesson, the value of knowledge remains and if we know how to find the antelope, we can eat.