Skip to main content
Article thumbnail
Location of Repository

Mentality Patterns: Recurring Turns of Mind as First-Class Concerns in Software Engineering

By Georgios Koutsoukos


A wide variety of sources indicate the existence of certain recurring turns of mind, usually referred to as mentality, that have significant impact in software engineering practice. Some of those turns of mind are established to the point that certain designations, for instance “not invented here” or “us and them”, have already been attributed to them. However, whereas agreement on existence is clear, there is significant ambiguity or even inconsistency in the way those are discussed and considered. In other words, there is a noticeable absence of a standardised and systematic means to define, characterize and communicate such recurring mentality elements. Consequently, existing knowledge and practices on the matter are kept on people’s minds or used in narrow contexts. Moreover, very little has been published on methods that can assist colleagues to approach the subject in their work practices in a more organized way.\ud This thesis reports on research performed over several years, from both a researcher and practitioner perspective in the “real-life” field, and makes the following contributions:\ud • It presents the notion of Mentality Pattern as an abstraction and representation primitive through which we can capture, make explicit, systematise and communicate such human-mentality elements.\ud • It uses the primitive to define a Mentality Innovation Sub-process as an organized way to infuse such mentality issues as first-class concerns into software engineering practice.\ud • It provides a support system through which a repository of mentality patterns and associated knowledge and experiences can be built and shared.\ud Results in practice are very encouraging in what concerns the capacity of the Mentality Pattern primitive to organize different perceptions, facilitate the identification of recurring “mentalities” and act as a common communication mechanism.\ud Moreover, there is evidence that for some mentality patterns the sub-process can drive a constructive change in the way people operate in teams. On the other hand, there exist recurring mentalities that are more persistent.\ud Finally, based on relevant findings, this thesis calls for an intensification of research on the mentality phenomenon in software engineering and makes concrete recommendations in that respect

Publisher: University of Leicester
Year: 2011
OAI identifier:

Suggested articles


  1. (1999). (eds.): Cognitive Dissonance: Progress on a pivotal theory in social psychology. doi
  2. (2001). A conceptual framework for studying environmental mentality and behaviour.
  3. (2004). A Framework for Empirical Evaluation of Conceptual Modelling Techniques. doi
  4. (1984). A new look at dissonance theory. doi
  5. (1977). A Pattern Language.
  6. (2008). A Survey of Social Software Engineering. doi
  7. (1957). A Theory of Cognitive Dissonance, doi
  8. (1999). Action Research. doi
  9. (2008). Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behaviour. doi
  10. (2011). Agile Alliance: — last accessed
  11. (2011). Agile Manifesto Signatories.
  12. (2001). Agile Software Development: The People Factor. In doi
  13. (2002). Agile Software Development. doi
  14. (2009). Alfresco 3 Enterprise Content Management Implementation.
  15. (2007). Alfresco Developer: Working with Custom Content Types.,
  16. (1978). An Assessment of the Scientific Merits of Action Research. doi
  17. (1997). Anticipating Change; Quality Software Management,
  18. (2006). Antipatterns: Identification, Refactoring and Management. doi
  19. AntiPatterns: Rafactoring Software, Architectures, and Projects in Crisis.
  20. (1993). Applications of case study research.
  21. (2007). Blog
  22. (1978). Characteristics of departments, positions, and individuals: Contexts for attitudes and behaviour. doi
  23. (2000). Characterizing People as Non-Linear, First-Order Components in Software Development. doi
  24. (1992). Choosing Information System Research Approaches.
  25. (1951). Client-centered Therapy. doi
  26. (2000). Collaborative Practice Research. doi
  27. (2010). Collaborative Software Engineering: Concepts and Techniques. doi
  28. (1994). Congruent Action; Quality Software Management, doi
  29. (1999). Constructing Social Psychology. doi
  30. (2004). Context Models for Managing Collaborative Software Development Knowledge.
  31. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. doi
  32. (2011). Designing a World-Ready Program. — last accessed
  33. (1977). Dissonance and Self-perception: An Integrative View of Each Theory’s Proper Domain of Application. doi
  34. (2005). Extending Agile Methods: A Distributed Project and Organizational Improvement Perspective. CrossTalk:
  35. (1984). Fifteen Years of Psychology in Software Engineering: Individual Differences &Cognitive Science.
  36. (1993). First-Order Measurement; Quality Software Management,
  37. (1964). Games People Play: Psychology of human relationships. doi
  38. (2002). Generalization in interpretive research.
  39. (1977). High-Level COBOL Programming. doi
  40. (1994). How Do Teams Shape Objects? -How Do Objects Shape Teams?.Workshop Report, doi
  41. (2002). How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering.White Paper, Valtech and Rational,
  42. (2004). Institute. Guide to the Project Management Body of Knowledge, A (PMBOK Guide). Project Management Institute, doi
  43. (2010). Interviews in Qualitative Research. doi
  44. (1996). Introduction to the Personal Software Process. doi
  45. (1999). Introduction to the Team Software Process. doi
  46. (1998). Introductory Psychology. doi
  47. (2003). Lazy Programming and the Acquiescent "It Works" Mentality Post,
  48. (2009). Magic Quadrant for Enterprise Content Management
  49. (2007). On Generalization in Qualitatively Oriented Research [23 paragraphs]. Forum Qualitative Sozialforschung / Forum:
  50. (2011). Ontology Language.—last accessed
  51. (1995). Patterns and Antipatterns. doi
  52. (2003). People and methodologies in software development.
  53. (1987). Productive Projects and Teams. doi
  54. (1994). Qualitative Data Analysis: an expanded sourcebook, 2nd edition. doi
  55. (2009). Qualitative Research doi
  56. Qualitative Research & Evaluation Methods, doi
  57. (2002). Quality Software Project Management.
  58. (2002). Reading qualitative studies. doi
  59. (2002). Real Web Project Management: Case Studies and Best Practices from the Trenches.
  60. (2011). Research Methods
  61. (1972). Self-perception theory. doi
  62. (1997). Software Project Survival Guide. doi
  63. (2004). Strategies for ensuring trustworthiness in qualitative research projects.
  64. (1992). Systems Thinking; Quality Software Management,
  65. (2011). The Alfresco Open Source Content Management System. — last accessed
  66. (1975). The Mythical Man-Month. doi
  67. (2003). The paucity of multi-method research: a review of the information systems literature. doi
  68. (2001). The People Capability Maturity Model. doi
  69. (1986). The problem of rigor in qualitative research. doi
  70. (1971). The Psychology of Computer Programming. doi
  71. (1955). The psychology of personal constructs doi
  72. (2011). The Software Development Life Cycle: When to Secure Your Process. — last accessed
  73. (2002). Three process perspectives: organizations, teams, and people.
  74. (1980). Towards a Definition of Action Research: a Note and Bibliography. doi
  75. (2004). What Is a Case Study and What Is It Good for?. The American Political Science Review, doi
  76. Who should work with whom. doi
  77. (1995). Why Does Software Cost So Much. doi
  78. (2003). Writing Good Software Engineering Research Papers – Minitutorial. doi

To submit an update or takedown request for this paper, please submit an Update/Correction/Removal Request.