Naturalness & Agility, the Forgotten and Abandoned Engines

Naturalness & Agility, the Forgotten and Abandoned Engines of Software Development

Social aspects of software development will provide a better knowledge of the software construction process and how individuals intellectually contribute to creating better, innovative products.

According to The Standish Group's 2020 CHAOS report, 66% of software projects fail. A survey by KPMG mentions that 70% of organisations have suffered at least one project failure every 12 months, and 50% said their projects had not accomplished their goals. But, Why? There are many reasons to fail, some of which are internal organisation issues, but the primary cause of all others is "Developing software unnaturally". Many software projects flounder because of the lack of information and 'social' bandwidth. Social bandwidth refers to the social interactions between members of the team. Good social bandwidth requires a very high information bandwidth. Software development today can be considered a participatory culture, where developers, testers, product owners, and stakeholders coordinate and engage together to develop software while continuously learning from one another and creating knowledge. Developing software is the act of a community; it requires a team with varied skills. The most productive teams recognise and encourage that skill variation and naturally strive to increase their social bandwidth to spread those skills and experience. Surprisingly, there is a deemphasises on the people factor even though the software is developed for people and by people. Human factors play a vital role in Software Development. And those factors span across a lot of different and diverse concepts and theories; coordination, collaboration, trust, expert recommendation, program comprehension, knowledge management, communities and culture in the development process. Some strange phenomena in software development are equally exciting and counterintuitive. Melvin Conway, who originally coined the term "Conway's Law", observed that because of the social nature of software development, the design of an underlying software system closely reflects the social relationships between its programmers. We need to talk to lots of people on your and other teams to understand the architecture, the interfaces and further details of the system. This phenomenon rarely gets the attention it deserves from software managers, although lots of evidence from Harvard researchers and Microsoft that it profoundly affects software quality. Despite its relevance, software testing is arguably the least understood part of the software life cycle which is the toughest to perform correctly. We focus more on the process and technology dimensions of testing and less on the human dimension of testing, despite the reported relevance of human aspects. It is essential for testers to understand various stakeholders' explicit and implicit requirements, understand the way developers work in teams & individually, and develop skills to report test results wisely to stakeholders. Exploring the human dimension may help understand and conduct testing in a better way. Social software testing approaches can be great recipes that testers can adapt to work together and improve their testing by contributing and learning simultaneously. The lack of knowledge of naturalness and agility leads to lack of dynamics in improvising solutions to solve complex problems and innovate. Awareness of the various psychological and social effects during software design will help you get the software built, tested and launched faster. This talk will combine software engineering approaches with social science, looking at software development from a whole new perspective, including those of naturalness & agility, to point out solutions and conditions for human-centred software engineering. As much as we say, writing code is a social activity; testing code is a social activity too.