Stop Working In Secrecy
Learn to work as a team
It is very hard (I’d say almost impossible) to create and maintain even a slightly complex software system when working as a single software engineer/developer. It always takes teams of software professionals to build and maintain software products. Even when a software product starts as a simple system built by a single developer, as the time progresses it grows beyond the ability of a single person to keep it operational.
When a software professional applies for a job that includes software development and maintenance, it comes as no surprise that the new hire will be joining a team. No one is expecting when applying for a software-related job that he or she will be working as a solo engineer/developer.
But then something interesting starts happening when a new hire joins the team of software professionals—he or she gets assigned a task, an item to work on. Why do I see that it is interesting? Isn’t that normal? Isn’t it expected that people who work on software projects need to be given assignments and tasks to work on?
Here is where the situation becomes a bit unusual. Unlike in some other work environments, where it makes sense to divvy up the workload and send each worker away to work by themselves on their task, it makes zero sense to take that approach in software.
Of course, software is not the only discipline where it makes zero sense to divvy up the workload and send individual workers away to work by themselves. Not every workflow is easily broken down into atomic tasks that can be done independently, in parallel. Whenever we encounter a situation where it is not possible for individual workers to take their item and work on it by themselves, we are dealing with teams. And the only way the teams can work effectively is if they embrace teamwork. Which means they are not splitting the workload into atomic tasks.
Take, for example, a jazz combo that is scheduled to deliver a performance. Each member of that jazz combo plays a different part, using a different instrument. And yet, it would be literally impossible to split the music up into separate tasks and then send each musician away to work on each part by themselves. If we were to insist they do that, it would mean that each musician would climb on the stage by himself/herself and play their entire set alone, in front of an audience. Then, when the first musician finishes, the next one climbs on the stage and plays his/her part. And so on. If the jazz combo consists of five musicians and if the set is scheduled to last for about two hours, that approach would then stretch the performance almost to ten hours! That would be very taxing on the audience, expecting them to sit through that nightmare.
Even worse than that, the audience will be asked, at the end of the entire performance, to integrate in their heads all the individual lines that each musician has played.
Who do you think would be prepared to pay the admission ticket to such an idiotic show?
Teamwork means working together at the same time
Another example of a real team is a sports team, such as a soccer team or a basketball team. They are a team not because they belong to the same sports club and they wear the same sports uniform. They are a team because they play together, and they play at the same time.
It would be equally ludicrous to arrange for a sports team to only have one player at a time playing alone in the field. There may be some talented basketball player who insists that he can only shoot hoops when no one else is on the field. But that’s not how the team can win the game, so that proposition is automatically off the table.
Is there such thing as a software team?
When we observe how software professionals work, we typically notice the following process:
There is a meeting when software professionals discuss what feature to implement
Once decided, the feature gets chopped up into smaller tasks
Each task gets assigned to an individual member of the group
The group disperses and everyone scatters to work on their individual assignment
The above process has nothing to do with teamwork. It seems like software professionals are merely members of some group, and they call themselves a ‘team’ simply on account of the fact that they are listed under the same label, the same group name.
In my experience, most people, software professionals as well as managers, do not think that there is anything wrong with that arrangement. They actually think that it is the best approach to building, releasing, and maintaining software.
So, we see that, in the majority of cases, there really isn’t such a thing as a software team.
Should there be such thing as a software team?
My view is that there must be a team who is responsible for developing, releasing, and maintaining software. Why do I think so?
Let’s examine a bit closer the typical way software is currently being worked on. As was mentioned above (the four steps that typically happen when people work on software), each member of the group is expected to accept an assignment and then go away to work on it. In effect, the group of software professionals scatters the moment the meeting is finished. They disperse and work in full isolation, in full secrecy.
Now, most software professionals I worked with insist that working in complete isolation is the best way to work. The way to do that is to grab a snapshot of the current state of the codebase (also referred to as a repo, short for repository), save that snapshot on an individual laptop (or desktop, as the case may be), and then spend some time in isolation, away from others, working in silence, making changes to the codebase. The technical term for that approach is "branching.” If the codebase that is in production is regarded as "trunk," when anyone takes a snapshot of it and saves it locally, they are technically “branching” from the trunk.
Of course, when someone is working on a branch that is stored locally on a laptop, that situation is the exact same as the previously described situation where a single member of a jazz band climbs on a stage and plays his or her part while no other band members are present. The content created and delivered while other team members are not present is incomplete. Why is it incomplete? Well, same as the lines played by a single instrument, in the absence of other instruments, create an incomplete situation. Only when all other instruments join in does the audience get a chance to hear the integral performance.
The keyword is integral experience. Same as with music performance, software also only works if all parts are simultaneously present. Which means any changes to software that were made in isolation need to be integrated with the rest of the system.
If five software professionals are working in isolation, each making changes to their own private, local branch, the longer they work on their private branches, the larger the effort will be to integrate their changes into the trunk. That’s one of the main reasons while teamwork in software is essential.
But there are other, equally important reasons why it is absolutely indispensable to work on software as a team. I’ll discuss those reasons at a later time.
Should working in isolation be evaluated as working in secrecy?
Whenever I discuss these issues with a typical group of software professionals, they vehemently push back. Whilst they may agree that they do indeed like to work in full isolation (“no interruptions”), they categorically disagree that by doing that, they are working in secrecy. They insist that there is absolutely no secrecy in their work. How do they prove that? They say that while they are working, they may send emails to other members of the group to discuss some issues, or they may send messages in Slack channels, etc. Also, once they are done, they open a Pull Request which exposes all the changes they’ve made to their local branch. The results of their work in isolation are available for all others to review in broad daylight.
Here is how I counter their arguments:
So, you go away and hide (create a branch on your laptop) and work on making changes. Of course, other team members know that you are working on your branch, but they have no idea HOW you are going about it. That's really bad. That's working in secrecy. Instead, make changes only in the presence of other members. That way you will ensure full transparency.
How to abandon working in secrecy?
Adopt the jazz combo working model. When making changes to the software, never make them while other members are not present and are not observing the changes being made. Cultivate social skills. Work together, at the same time, face-to-face. Discuss as a group every code change. Share the knowledge in a given context. Learn from each other, and elevate each other. Respect your colleagues, and never work behind their backs. Never force them to have to do a lot of heavy lifting in order to integrate the changes you’ve done in secrecy.
Outlaw any work in secrecy in your organization. Favour working as a team in real time. Do not burden your colleagues with your secret escapades when you create those mysterious branches. People are not mind readers, and they have no idea what kind of changes you are making while messing around with your private, local branch. It is unfair to ask your colleagues, after spending a few days of making all kinds of changes, to review them and try to retrofit them into the trunk. That’s brutal and very unprofessional.