I have written down the rationale behind the Reflective Developer Program in the following pages, ending with a brief introduction to the program:
1. The state of software development in some trenches.
Sunday, November 10, 2013
4. Learning from other communities of inquiry
There are a number of works on epistemology —as philosophy of science— and on general theory of knowledge —or gnoseology, as known in some Latin-derived cultures— that have been very significant on my research. For example, Ernst Cassirer’s works study knowledge as a philosophical problem and its implications on the development of human culture:
- The Philosophy of Symbolic Forms: Vol. 3: The Phenomenology of Knowledge.
- An Essay on Man: An Introduction to a Philosophy of Human Culture.
The philosophical perspectives predominate over strictly scientific perspectives in Cassirer’s works. I have found a more balanced treatment between philosophy and science in Mario Bunge’s two volumes on epistemology:
- Philosophy of Science: From Problem to Theory.
- Philosophy of Science: From Explanation to Justification.
Introductory works more on the side of strictly scientific perspectives that I have found very helpful are:
- What Is This Thing Called Science? by Alan F. Chalmers.
- Scientific Method in Practice by Hugh G. Gauch Jr.
- Theory and Reality: An Introduction to the Philosophy of Science by Peter Godfrey-Smith.
Then, there is this contemporary scientist, Rupert Sheldrake, who —as Paul Feyerabend in his own time— presents quite intriguing, or even interesting, arguments that shake popular understanding of scientific thought in his work:
- Science Set Free: 10 Paths to New Discovery, USA Edition.
- The Science Delusion, UK Edition.
Among the first works that indirectly pushed me to all the mentioned readings was this:
- Testing Computer Software, 2nd Edition by Cem Kaner, Jack Falk, Hung Q. Nguyen.
All this, and the following works by Donald A. Schön, has led me to pursue the development of what I have called a Reflective Developer Program, as a contribution to better professionalism in software development. A reflective developer is someone who tries to realize how thin her received piece of jam really is, and tries to make it thicker.
- The Reflective Practitioner: How Professionals Think In Action.
The Reflective Developer Program is intended to be a personal research journey to better understanding of professionalism in computing. Given the philosophical problem of knowledge and The Law of Raspberry Jam, I think that teaching and learning in our profession need to be rethought. Therefore, after studying the following works, I have found that dialog and discussion among practitioners is the appropriate thing to do.
- Turning Learning Right Side Up: Putting Education Back on Track by Russell L. Ackoff, Daniel Greenberg.
- Up and Out: Using Critical and Creative Thinking Skills to Enhance Learning by Andrew P. Johnson.
- Discussion as a Way of Teaching: Tools and Techniques for Democratic Classrooms by Stephen D. Brookfield, Stephen Preskill.
- Developing Critical Thinkers: Challenging Adults to Explore Alternative Ways of Thinking and Acting by Stephen D. Brookfield.
3. The Law of Raspberry Jam
«The Law of Raspberry Jam: The wider you spread it, the thinner it gets.» —Gerald M. Weinberg
As Gerald M. Weinberg said in his work The Secrets of Consulting about The Law of Raspberry Jam: «Another way of expressing the law is this: Influence or affluence; take your choice.» That is, the wider the audience, the more money you can make. Based on the observed effects so far, maybe we could know which has been the choice of the authors of ideas like the agile methods. I am glad they chose to spread their ideas; otherwise, maybe, I could not hear anything about such wonderful ones.
After some years studying about the philosophical problem of knowledge, I think that the choice of influence —as in The Law of Raspberry Jam, alternatively expressed— is exclusively a personal one. That is, I have received my part of jam, as thinner as it could be; now it is my choice to make it thick by means of self-influence: by personally researching the subject matter in order to get the more jam as I could possibly grasp.
For example, in my own research efforts, one of my null hypothesis is that the actual properties of the outcome of a non-trivial software development effort is an epistemic problem; that is, the actual properties of the outcome cannot be known until such outcome is actually experienced by its ultimate customers or end users; most previously conceived rationalizations must be doubted and put to rigorous empirical examination. Another null hypothesis is that the previous one will continually be true indefinitely because of the problem-solution coevolution model of design, where the sole presence of a solution to a complex problem —or a subset of the solution— redefines such a problem.
A trait of my provisional conclusions is that the very activity of software development for non-trivial projects is an activity of inquiry, of an experimental nature. This is true regardless past, current and future buzzwords because most of them, e.g., agile, are not intended to bring new knowledge but just new wrappings for already conceived and published ideas of the past. Part of the support for such conclusions can be traced in the works by early authors in our field, e.g., Gerald M. Weinberg, Frederick P. Brooks, Jr.
The practice of discussing these topics in communities of inquiry, and learning from the feedback, is another way to self-influence.
2. Agile impressions
Why are things as they are? How might things be different? Some years ago I started a personal inquiry guided by questions like these. Just recently I read the Agile Impressions text by Gerald M. Weinberg. I have read many of Weinberg’s books, and I have read that some Agile Manifesto’s authors have learned a lot from those books. That is why I am especially interested to read what Gerald M. Weinberg has to say about the Agile Manifesto’s mindset.
The section Agile and the Definition of Quality, as properly stated at the beginning, is adapted from section 1.1 A Tale of Software Quality, in Quality Software Management. Volume 1: Systems Thinking. I noticed that Weinberg equates the actions of a quality manager —as of 1991— with the actions of an Agile team —as of 2013—.
1991: «That’s why one of the most important actions of a quality manager is to bring such decisions into consciousness, if not always into public awareness.»
2013: «That’s why one of the most important actions of an Agile team is bringing such decisions into consciousness, if not always into public awareness.»
That is pretty much consistent, historically, with the quotation attributed to Weinberg in the article about the history of iterative and incremental development, by Craig Larman and Vic Basili: «...where the technique used was, as far as I can tell, indistinguishable from XP [eXtreme Programming].»
In other words, this is additional evidence for many possible conclusions; for example, that iterative and incremental development (IID) was not born with object-oriented methods in the 90’s, or that IID is not recent and comparatively unproven. Also, this is evidence of how true David Parnas statement is about where the next big thing in software engineering lies, in the horizon or in the past, in the history of our profession.
1. The state of software development in some trenches
The industry of software development has a history of its own ideas like structured analysis, design and programming, or object-oriented, or functional programming, agile methods, software architecture, and so on. In order to learn about some of those ideas, over many years, I have been involved with communities that form around those ideas, learning from authors and practitioners, and from my own application of those ideas to improve the quality of my own software design and programming practice. Along the way, I have tried to discuss with others about all that good stuff of software development as a cooperative game.
As years come and go, I have found teams and individuals that expose themselves to be influenced by ideas in the industry around, and the degree of such influence varies widely. There are still lots of programmers and managers who simply do not care enough to not just repeat the buzzwords but to behave like if they properly understood the concepts. Comes to mind what have happened with other intellectual pursuits in history. For example, very few people around me, even with several academic computing degrees, are able to articulate, in simple terms, the most general justified true beliefs from quantum theory, much less its relationship with the current computing industry. Whereas those justified true beliefs were published almost a century ago!
The Reflective Developer Program - what is it about?
Which is the opportunity?
The program intends to attend as a sparring partner for the individual professional. The program proposes a community of inquiry on the topic of professionalism in the creation of software-based business solutions. In this community the individual can compare notes with others openly and without corporate hierarchies of any kind.
One goal is to assist the individual in his attempt to become more aware of his own personal condition with respect to a broad conception of professionalism. This includes, among other things, be familiar with the perennial problems of knowledge in general and the manifestations of those problems in the context of creating software solutions.
As a start, a collateral effect of the dispersion of knowledge: the more it is spread the less it is fully understood. So it is very likely that a conception we have of a given subject matter, however much we think we have it right, could be only a pale, shallow and distorted fragment of the originally conceived and developed idea.
Because of that collateral effect we could often act on the basis of deficient knowledge in the average case, or mere wrong-headed opinion at worst. The crux of the problem is to remain with that kind of knowledge as the basis for our actions in our profession. So the pursuit of professionalism must embrace, as a recurrent task, a critical appraisal of the real quality of the knowledge that we have about the most important ideas that guide our professional behavior. For example, the notion of «analysis» and «design», are they activities?, are they stages?, what theoretical frames sustain the possible answers?
Certainly, an improved understanding of our applied ideas produces an improved professional practice. Taking more instruction could improve understanding. But, if the institutional channels for spreading knowledge, like historically derived systems from scholasticism —or philosophy of school—, were not part of the cause that distorts such knowledge, then we could say that these channels are enough to improve understanding. Of course, they are not enough. Here is the niche of opportunity for the Reflective Developer Program.
How to improve understanding?
The central proposal is that the individual professional can become her own primary influence to improve the understanding of her own ideas. However, it is easier said than done. The difficulty lies in the little mental space that is often left to the individual after being invaded by a flood of information of all kinds —voluntarily or not— and from multiple channels simultaneously in our today increasingly interconnected society. The Reflective Developer Program recognizes that more information does not amount to more understanding and, therefore, opens up a space for the individual to pause, to analyze her ideas, to question them and then she develops the reformulation that is required of them.
For the problem is not what we ignore but what we have as true that ends up distorted or completely false. That is, the problem is not that we ignore many things or that we lack a wealth of information but to keep mere opinions due to misinterpretations of the information already received. So the proposed program is not just about self-taught learning but about the theory and practice of self-re-education.
The program aims to understand self-re-education, mainly, as unlearning, because that is precisely what is required to improve understanding. Get rid of misconceptions that hinder proper assimilation of knowledge is an essential step to improve understanding. In other words, as some education scholars have already noted, the contemporary illiterate is not the unable to read or write but the unable to learn, unlearn and relearn.
Next steps
The Reflective Developer Program consists of a series of conversations by which the reality of concrete situations are explored, situations that have professional relevance to participants. For example, the situation can be the design of a strategy for handling exceptions in a solution under development, or the dependencies between business logic components and data access components for proper control of distributed transactions, or maybe the analysis of an autonomous or semi-autonomous functional capacity to be released to the business regardless of other capabilities, etc. The Reflective Developer Program proposes a set of processes for analysis and synthesis applied to specific and relevant situations, it discourages overly abstract prescriptions that are illustrated with trivial examples that have no connection to the reality of the participants; that is, the program encourages the identification of defects in how we think, does not prescribe what ought to be thought.
For beginners in the program, the first step is that they are invited to participate as observers in a conversation where someone experienced reflects on a particular situation. So they could become familiar with typical protocols to identify contexts, to discuss conceptual structures or assumptions, judgments, arguments, fallacies, empirical analysis, experimental models, further sources for more information, and so on; that way they could witness the application of intellectual standards of systemic rigor.
For the case of non-beginners, the usual next step is to ask them for any concrete situation for which they want to initiate the cooperative process of reflection.
Subscribe to:
Posts (Atom)