Phenomenal Software Development

Over the next few posts I am going to cover the ground of Software and Phenomenology that I dealt with in my recent talks.



WHY EXPLORE PHENOMENOLOGY?




As we have progressed through the industrial revolution into our current wide ranging use of information technology, there has been a big change in the form of the tools that we use. The massive impact of this transition from external physical tools to internal virtual tools has largely been unconsciously experienced.



Edgar Dykstra back in 1972 was a notable exception when he gave a talk saying:



"AUTOMATIC COMPUTERS HAVE NOW BEEN WITH US FOR A QUARTER OF A CENTURY. THEY HAVE HAD A GREAT IMPACT ON OUR SOCIETY IN THEIR CAPACITY OF TOOLS, BUT IN THAT CAPACITY THEIR INFLUENCE WILL BE BUT A RIPPLE ON THE SURFACE OF OUR CULTURE, COMPARED WITH THE MUCH MORE PROFOUND INFLUENCE THEY WILL HAVE IN THEIR CAPACITY OF INTELLECTUAL CHALLENGE WITHOUT PRECEDENT IN THE CULTURAL HISTORY OF MANKIND."



Currently our society is heavily based upon the underlying Cartesian dualistic worldview. Along with this orientation we tend to focus primarily on results and though this has been necessary, it has some significant negative consequences. I believe that with the move to virtual tools, the cracks are beginning to show in the Cartesian worldview and its appropriateness for modern times. As computing has progressed along with this has been a questioning of just what it is to be human.



I consider that phenomenology - regardless of whether you can pronounce it or not! - can lead us to a more integrated worldview and I believe the industry needs this more balanced, more human, view if it is to constructively progress.



OVERVIEW



I will be starting by providing an overview of my own background. This is important so that you can get a sense of the experiences and thinking that have shaped my conclusions. Only then can you be free to decide what you want to take and what you want to leave.



Then I give some key observations that I've made through my career particularly the one about what I call 'Boundary Crossing', followed by a short overview of some philosophical ideas. But please note I am not an academic philosopher. Two particular philosophers I highlight are Descartes and Goethe as they represent two realms of thought that I consider relevant in their impact on software development. Notable issues here are: Knowledge Generation, Imagination and the Patterns movement.



I then have some conclusions about how we might progress into the future - both with technology development and technology use.



A PROGRAMMER'S BACKGROUND : NOVICE - THE EARLY YEARS



I started out being interested in electronics at 17 back in 1974. Originally I was a shy young adolescent nerd who found comfort in the inner world of thought. Also I was not good at dealing with members of the opposite sex, which I believe could be quite a common phenomenon among younger software developers.



Thereafter I gained entry to Southampton University in order to study electronic engineering gaining my degree in 1979. Even at this stage I realized that I wanted to move from hardware development to software development, although I only had an unconscious sense of this physical to virtual transition.



Early programming tasks were a hobby at the time and were based on programming games in BASIC on computers I had built from a kit. There was an initial foray into trying to do an IT records management application which I messed up completely.



Then came the job in the field of media TV and film editing systems where I was definitely feeling that I was working with "cool" tech. Definitely a time of being enticed by the faery glamour of the technological toys.



A PROGRAMMER'S BACKGROUND : JOURNEYMAN - THE DANGEROUS YEARS



It was the next phase of the career that I call the dangerous time. A time characterized by the following traits:



* Wanting to play with more complex and generic structures. (Many of which did not actually get used!)

* A focus on the tools rather than the problem.

* The creation of unnecessarily complex systems, letting the internal idea overshadow the external problem context.

* An arrogance about what could be achieved - soon followed by absolute sheer panic as the system got away from me.

* No realization that the complexity of thought required to debug a system is higher than that required to originally design and code the system.



This phase of a career can last for a long time and highlights the fact that the programmer needs to become more self-aware in order to progress from this stage. In fact some people never do.



This can be a real problem when recruiting experienced programmers. When interviewing I separate the time into two sections. Initially I ensure that the interviewee has the required level of technical competence, and once I feel they are more settled I move on to see just how self-aware they are.



One question I use here is 'So tell me about some mistakes?' There are two primary indicators that I am looking for in any response. The first one is the pained facial expression as they recall some past mistakes that they have made in their career and how they have improved in the light of those experiences. The second is the use of the word 'I'.



'I' is an important word for me to hear as it indicates an ownership and awareness of the fact that they make mistakes without externalising or projecting it onto other people or the company. This is important because it will show the degree of openness that the interviewee has to seeing their own mistakes, learning from them, and taking feedback. A programmer who cannot take feedback is not someone I would recruit.



A PROGRAMMER'S BACKGROUND : GRUMPY OLD PROGRAMMER



This 'Old Grump' phase is possibly a new one that developers go through before reaching Master level. I hesitate to describe myself as Master but am currently definitely at the Old Grump stage! Traits here I have experienced are:



* Awareness of the limitations of one's own thinking, after realizing again and again just how many times one has been wrong in the past. Particularly easy to notice when debugging

* Realization that maintenance is a priority, leading to a drive to make any solutions as simple and clear and minimalist as possible. Naturally the complexity of the solution will need to match if not exceed the complexity of the problem. Once one has experienced the ease with which it is possible to make mistakes it is always worth spending more time making solutions that are as simple as possible, yet do the job. An Appropriate Minimalism.

* Code ends up looking like novice code, using complexity and 'big guns' when required.

* A wish to find the true essence of a problem, but when implementing using balanced judgement to choose between perfection and pragmatism.

* Most people think that because you are more experienced you are able to do more complex work. The paradox is that the reason you do better is that you drop back to a much more simple way of seeing the problem without layering complexity upon complexity. (This strongly correlates with the phenomenological approach)



Next I will be talking about some of the observations I have made throughout my career.

Until next time
Full Post