Published by OpenTask, Republic of Ireland

Copyright © 2013 by OpenTask

Copyright © 2013 by Software Diagnostics Services

Copyright © 2013 by Dmitry Vostokov

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without the prior written permission of the publisher.

You must not circulate this book in any other binding or cover and you must impose the same condition on any acquirer.

Product and company names mentioned in this book may be trademarks of their owners.

OpenTask books and magazines are available through booksellers and distributors worldwide. For further information or comments send requests to [email protected].

A CIP catalogue record for this book is available from the British Library.

ISBN-13: 978-1-908043-57-3 (Paperback)

First printing, 2013

 

 

 

 

Hello Everyone, my name is Dmitry Vostokov and today I make the first step towards a philosophy of software diagnostics. I decided to keep this presentation as short and simple as possible without using specialized philosophical jargon. If anything needs to be added or modified in the future I create another version of it. This is also the part one of the introduction because as a practicing software diagnostician I didn't have much time to process and include all material that I planned initially. So I promise to deliver the subsequent parts later. In this part we cover mostly phenomenological and hermeneutical approaches to software diagnostics and leave analytical approaches for the second part.

 

 

 

 

Let me prefix the presentation by extending thoughts of the great Roman physician and philosopher Galen to software diagnostics.

 

 

 

 

These prerequisites are very simple and I suppose you all, like me, enjoy diagnosing software problems, troubleshooting and debugging. Also philosophical attitude presupposes interest in deep meta-questions. In our interpretation of meta-, “What is a problem here?” is a question, but “What is a problem?” is a meta-question.

 

 

 

 

Our goal is to synthesize the philosophy of software diagnostics from the software diagnostics practice itself.

 

 

 

 

Before we start with philosophy I would like to remind you about a definition of software diagnostics that we put forward in our previous webinars. Notice the appearance of a word “pattern” here. So what is a pattern then?

 

 

 

 

The definition of a diagnostics pattern is more general because it applies not only to software artifacts but to hardware and software diagnostics itself and if you'd like it can be applied to general diagnostics as well. Notice also the appearance of a word “problem” here. Obviously, in the previous definition the so called “abnormal software structure and behavior” is also some kind of a problem. Therefore, to understand a diagnostics thought process and diagnostics patterns we need to ask a further question.

 

 

 

 

There are many definitions of a problem especially from the problem solving perspective. But a diagnosis is not a problem solving and before doing correct diagnosis we must be sure that we have a right problem but to find out whether we have a right problem we need to perform a correct diagnosis. Vicious circle. So we need a very simple definition of the problem that doesn't involve a diagnosis. We consider problems from human computer interaction first because such interactions are everywhere and involve everyone including the vast industry of software support. In order to find out the best definition we opened Historical Thesaurus of the Oxford English Dictionary, 2 volume set.

 

 

 

 

Historical thesaurus shows the concept variations in time and adds an additional dimension to the meaning and can be a source of new ideas. On the slide I put an excerpt from different domains. The main meaning there is “Difficulty”. We have a problem when we have difficulty while interacting with software. We consider enquiry, questioning and discussion later. With such a definition if we have a memory leak but if it is going unnoticeable we don't have a problem. Notice the abbreviation of problem as prob and use it as such in mathematics. To differentiate our problem from any other definition we came up with a new word for it.

 

 

 

 

We call it prob-lemma. What is a lemma part? In mathematics, lemma is defined as a proven proposition which is used as a stepping stone to a larger result. In our context it is a tentative proposition about a probable problem. It is often a case that a problem disappears before diagnostics starts or is relative or stems from software user misunderstanding. We define prob-lemma as a pair: it is an issue for a software user (difficulty) but an understanding of it is absent or vague or incomplete. Tilde here means a negation, a negation of understanding of the issue. The first time I see my Russian roots help me in problem solving, in problem solving the problem of the problem.

 

 

 

 

Sometimes we are lucky and understand a problem but most of the time we don't have its understanding.

 

 

 

 

The key to understanding is a projection of a problem to patterns. But not all patterns are good for understanding. We need…

 

 

 

 

…patterns in artefacts. By an artefact we mean a memory dump, or live memory (which is a sort of a memory dump), software traces and logs whose messages can be considered as fragments of memory similar to memory dumps. And so we come to a second concept called…

 

 

 

 

Da- in da-sign means a dump artefact and a -sign part means just a sign, a pattern. If we able to get a collection of da-signs for a prob-lemma we get full understanding of an original problem. You may have noticed that Da-sign is similar to Da-sein introduced in influential “Being and Time” philosophical log from Martin Heidegger, a German philosopher. It means “being there”, a peculiar human being whose being is an issue for it and it has an understanding of it. In our context da-sign means “a sign there, in a dump”, a peculiar software structure and behaviour sign that we are aware of and have an understanding of it. Note a word “understanding here”. We now come to the question of understanding. But before we consider understanding we would like to note that da-signs are not floating in isolation. We need a meaning-structure for them.

 

 

 

 

We call it CARE. Originally it meant crash analysis report environment or computer analysis report analysis. Da-signs are themselves meaning-patterns and CARE is their underlying meaning-structure. Now we continue with the question of Understanding.

 

 

 

 

Software Diagnostics is a practice and based on a dialog, understanding and interpretive interactions between a software diagnostician and a software user. Such meetings and dialogs are even more important in the case of remote interactions.

 

 

 

 

Here on this diagram I depicted possible interaction parties. For large software vendors and their customers there can be even more intermediate interactions until finally an artefact is opened in some analysis tool. There can be several software diagnostics practitioners such as technical support engineers, escalation, technical relationship managers, maintenance software engineers and software product developers.

 

 

 

 

Software diagnostics as a practice involves humans using software. Therefore it is beneficial to consider both software users and software when thinking about software diagnostics.

 

 

 

 

Working with patterns of defects makes one understanding of software better. When a breakdown of a computation happens we notice a pattern of software structure and behaviour and add it to a catalogue.

 

 

 

 

Understanding goes with interpretation. Due to various omissions, insufficient and incomplete interaction documentation it is always possible to interpret or misinterpret problem differently due to shifting requirements, different normative and political considerations. There can be different sources for interpretation.

 

 

 

 

I became interested in phenomenology last year. In the context of software diagnostics it is about the meaning and structure of everyday software diagnostics activities.

 

 

 

 

Additional feature of phenomenology that can be useful for holistic philosophy of software diagnostics is its inclusion of the human side.

 

 

 

 

I borrowed meaning-structure and meaning-pattern words from the book on phenomenology and hermeneutics of medicine I reference at the end of this presentation.

 

 

 

 

Here I highlighted some features of software diagnostics phenomenology.

 

 

 

 

Hermeneutics is about interpretation and understanding. It involves the analysis of narrative stories and in software diagnostics there are different types of them to consider.

 

 

 

 

Usually phenomenology goes with hermeneutics. Typical example here is problem description narratives that can be interpreted and understood with the help of problem description patterns.

 

 

 

 

Software diagnosis provides possible explanation for the problem. After finding da-signs we refine our prob-lemmas and provide explanation, recommendation and possible solutions for the original software problem.

 

 

 

 

As a conclusion you see that software diagnostics is mainly human-assisted. What about computer assistance?

 

 

 

 

The medical diagnostics was used as a systemic prototype for analogy and metaphors. However, there is crucial difference here. In medicine the logic of software is imposed on medical diagnostics (the so called analytical approach) but in software diagnostics software is inherent. So we come to the analytical philosophy of software diagnostics.

 

 

 

 

We leave it for the second part we plan to introduce in a few months.

 

 

 

 

Originally we planned this webinar to be focused on abduction only. What is abductive reasoning you see from the example here. Abduction is very common in medical diagnostics and law, for example. However, we found that software diagnostics was missing philosophical foundations and prepared this webinar instead. We promise to cover abductive logic and its relation to philosophy of software diagnostics in the next part.

 

 

 

 

Here are some books I recommend to read. The first one (unfortunately is only available for Russian readers) was very influential for me to see the possibility of software diagnostics philosophy. The second one, an introduction to metaphysics, prompted me to delve deeper into a definition of a problem word. The next two books: Being and Time and its interpretation guide gave me ideas for da-sign. And finally, the book about hermeneutics and phenomenology gave me ideas on meaning-structures and meaning-patterns. The second section lists resources for pattern-oriented software diagnostics.

Software Diagnostics Institute:
http://www.dumpanalysis.org

Memory Dump Analysis Anthology volumes:
http://www.patterndiagnostics.com/ultimate-memory-analysis-reference

Introduction to Pattern-Driven Software Diagnostics:
http://www.patterndiagnostics.com/Introduction-Software-Diagnostics-materials

Introduction to Systemic Software Diagnostics:
http://www.patterndiagnostics.com/systemic-diagnostics-materials

Introduction to Pattern-Based Software Diagnostics:
http://www.patterndiagnostics.com/pattern-based-diagnostics-materials

Introduction to Software Narratology:
http://www.patterndiagnostics.com/Introduction-Software-Narratology-materials

 

 

 

 

For those who consider that life is similar to software I provide this pictorial analogy. Philosophy of Heidegger incorporates death as an inescapable part of human being and we also consider “blue screens of death” as an inescapable part of software. Note that the philosophy of Heidegger is considered as a philosophy of death and a philosophy of a new beginning.