Re: Psychological Effect of software defects

[Kutar Maria]

Posted for Chris Martin:

________________

Hi Neil,

I have a couple of (painfully long) perspectives that may be of some value:

[1] first as a developer…

There are a couple of important things to take into account; to generalise is to deny the nuance and detail, the trick is capturing enough detail to ensure your findings hold value to more than a sample of one. Until very recently I worked for a fairly substantial company delivering a market leading SaaS product to tens of thousands of customers, the code base was non trivial architecture equally interesting. As with many modern tech companies it was sales lead company, so the bulk of the decision making was driven by adding customer value, which is fine, we all like getting paid at the end of the day. 

However this results in high levels of un paid 'technical debt’, (that let just make it work and we will refine it next time we are near it, kind of stuff). When a valuable customer gets on the phone you want to be able to respond quickly so it is typical to have a SWAT team (SoftWare Action Team) that are not working on features and are able to respond quickly to customer issues. It is fair to say that there were developers that enjoyed this type of work, dropping into unknown areas of the code base, and developing and refining strategies in determining what was going on. This often requires high-levels of communication with other teams and functions with in the business which is another dimension. 

I think it would be fair to say that the majority of the 80 or so dev team were less enthused by this type of work. There is a key distinction in what this work is (which i think is relevant to your question). In a sales lead, (short term) value driven organisation without much engineering nouse at high levels, bug fixing is often patching up, chasing the minimum viable to get the issues resolved quickly. Pleasing customers is the goal and they don’t see elegant solutions they se stuff working or not. All the developers I worked with hated this, there is a huge amount of amount of artistry in good engineering and in the same way Mathematicians will talk of elegant proofs, all the engineers I respected wanted to make things better, not just work. I think it is important to distinguish between a bug fix (just make it work) and a refactor (make it work but improve the design and implementation). There is definite pleasure in taking some un readable (1000 line css or bloated multi responsibility class), unnecessarily complex ‘thing’ and producing an elegant solution, whether its minimal extracting a few methods to make the main flow of the code more readable or applying a software pattern, or simply removing stuff that is no longer needed (in big code bases even with good tool removing stuff is often quite tricky and risky).

So for sure Dev live to solve problem, they also take a great deal of pride in what they do, most that I have talked to who are in a just make it work quick type of gig are often not that happy.

[2] from my PhD research- Emotion…

I am interested in enabling great learning experiences in programming and understanding the design decisions that go into this. I conducted a bunch of empirical work with a range of learners engaging in different introductory programming tasks and one of the measures I used was capturing emotional response to programming. Lots of CS ed is knowledge driven and thats fine, we certainly don’t want to remove that in an effort to make programming accessible!

My work looked at shifting the focus of learning experience design to consider the context and the learner a little more. The challenge with measuring anything is you will have an impact on the thing you re measuring. For my work to minimise this I developed a tool, the Reflective Emotion Inventory that was used at the end of the session to capture learners emotional response to the activity. It made use of an ontology of emotions from the HUMAINE project. In the first pass participant would mark on a unipolar likert scale the intensity of each emotion from 0 - 3 or not experienced to strongly experienced. The second part encouraged participants to offer some 'free text' description of the context in which the emotion was experienced, e.g frustration - “trying to get the wires in the correct holes on the bread board”. In all my studies I found a balance of negative and positive emotions, with the positive greater than the negative. As the learning experience began to become more tailored to the learners both negative and positive emotions remind but the intensity of the positive one grew. 

I believe this models programming in a very broad sense we take steps into the unknown and express our intentions in code and then have a variety of way of confirming if we have produced code that meet our expectation, if not we iterate (or abandon) until we get to a desired solution which is where the positive emotions come form. I captured this concept in my thesis in a Learning Dimension (These owe a lot to Thomas, Marian and the rest of the CDs community) called Risk and Reward. Essentially when we engage in a task we accrue risk until we have an opportunity to confirm our intentions are correct. This may be a peer review, a compiling program (or in industry a passing unit test or build). I believe this ratio of risk to reward has bearing on the emotional response a learner or developer will have to what they do.

Happy to share this or discuss further if you think it would be valuable, I am an engineer foremost so it could definitely do with some love from Psychologist!

Cheers,

Chris 

PS. there is no denying there is an important understudied emotional dimension to programming the EKCD comic about code quality being measured in WTFs per minute is testimony to that :)

_________________________
Chris Martin

Life Sciences - CTIR
University of Dundee
cjma...@dundee.ac.uk
@sspog

The University of Dundee is a registered Scottish Charity, No: SC015096

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Dr Maria Kutar

Associate Dean (Academic - Student Experience) |  Salford Business School

Lady Hale Building, University of Salford, Salford  M5 4WT

t: +44 (0) 161 295 3056

m.k...@salford.ac.uk  | www.salford.ac.uk

http://www.salford.ac.uk/business-school/business-academics/maria-kutar