What can a program code tell us about social interactions and psychology of people working on a project?
When I was maintaining a legacy application, I usually didn’t have a good opinion about the code. At first I blame a programmer for wrong design etc. Now I know that programmer’s skills of programming are not the only thing that influence the code design. Code structure is also reflected by social interactions and psychology of people working on a project.
We have two person team, John and Mark. John is programming business logic, Mark is programming GUI. Let’s say that they have created half of the application. Business logic and GUI are connected though API.
What API would be created, if they:
- didn’t have good communication
- had excellent communication
- didn’t like each other
- didn’t have much time
If there were no communication, it is possible that GUI wouldn’t have all functionalities or it would be slow. Both would think that they done his part and that the application is completed.
If there were excellent communication, it is possible that minimal code is written and the application would be completed.
If they didn’t like each other, John would create API that would be hard to use.
If John wanted spent as little time as possible, he would create API, where all business code had to be implemented by Mark on GUI.
If Mark wanted spent as little time as possible, he had to get API with all desired functionalities.
Code changes are also interesting. For example, if a design was bad and an upgrade is made, would programmer who maintain code create fix in “his” code or would communicate with other members if code could be fixed on the source of a problem?