Meaningful software is so large is simply must be produced by a group of people. However, getting a group of people working well together can be quite difficult. Group dynamics are certainly not unique to SE and we see techniques to make high functioning teams from everything from sports teams to kitchens. However, SE has specific aspects in terms of our culture, beliefs and attitudes that should well considered. Interestingly, though the data collected after much studying suggests that the sameness might overwhelm the difference so I encourage students to be a bit broader in allowing SE group learnings from many disciplines.
Some of -ilities like security, reliability, etc. are not user focused, but many are including:
The system provides the required functions - Utility
Ability to access the systems and its function - Availability
Ability to access the systems within acceptable time - Performance - ility :-)
Ability to be able to use the functions - Accessibility
Ability to be able to use the functions successfully - Usability
Ability to enjoy the functions - Satisfaction (Satisfiability)
These -ilities are architectural decisions that have to balance costs and some of them are at tension meaning that we might not be able to do everything in some perfect way (aka we must except trade-offs here)
Meaningful work requires teams, unless we are very willing to extend time the iron triangle of the next segment forces us to add resources and with such an addition comes challenges. There is overhead with teams in the form of communication and coordination. Add to this that we humans are not interchangeable resources, but unique people with a wide range of abilities from 1x to 10x so to speak. We quickly find that IQ will not make up for a lack of EQ with teams and even the most technical proficient team may devolve into a mess. While SE has some specific aspects, a group of humans working together on a shared cause is fundamentally not a unique concept and we should first aim to understand the broad concepts of group dynamics and see the particular software and software industry nuances second. Simply put, to get better at Software Engineering in groups we should admit that as software practitioners we might be spending a bit to much time on the procedural how and not the who of our constructive efforts.
Again many of these ideas seem to involve a value judgement upon developers. We produce product of the mind and often to do it well we need heavy concentration and flow. The need to interact with others also may not come natural given the types of folks who find such problem solving motivating.
Our industry does continue to promote the idea of brain power trumping social understanding especially in the light of the hooded hacker alone slaying a hard technical challenge. This heroic view of our work is in fact mostly a myth, representing special cases often from longer ago when software wasn’t quite as ingrained in our society requiring it to be done at scale.
In short, our resistance to teams often comes from a lack of shared positive experience with them, such as what might happen in this very class coupled with the control we can exhibit as a solo developer. Further, we might add into this a reasonable unfamiliarity we might have with such soft or social dynamic skills, but it is of my opinion as well as the majority of academic and industrial SE community that these are important skills and we very much can learn them. The first step though came from the previous segment were self-mastery must be achieved before moving on to group mastery.
Test Questions