In the world of software development, there’s a silent yet quite popular practice that often goes unnoticed until it’s too late. It’s the habit of programming in isolation, a phenomenon I like to call “cave programming.” This approach seems efficient at first glance but often leads to significant pitfalls in the later stages of development.
Take the case of Bob, a talented developer in a mid-sized tech firm. Bob is known for his dedication and the ability to churn out large chunks of code. However, he tends to work in isolation, only emerging from his ‘coding cave’ after days or even weeks of solitary work. This habit, though born out of a desire for focused productivity (and other some other factors, we will discuss), often backfires.
Recently, Bob spent weeks developing a complex feature for the company’s flagship product. When he finally presented his work, it became evident that his understanding of the requirements had diverged from what the team had envisioned. The code, while brilliantly written, was misaligned with the project’s goals and required significant rework. This not only demoralized Bob but also set the project timeline back by several weeks.
Do you know any Bob around you? Even better, are you the Bob yourself? Then you are at the right place. Read on.
Bob’s story is not unique. It’s a scenario that plays out in many software teams across the globe, leading to rework, missed optimization opportunities, and a significant drain on time and resources. This article aims to find out why this happens and also to shed light on the importance of early feedback in the software development process, advocating for a shift from ‘cave programming’ to a more collaborative and iterative approach.
Why (many) people prefer working in silos?
Multiple factors drive one individual to get involved in cave programming.
Many developers choose to work alone because they think great work needs a lot of quiet time. This way of thinking, where someone works alone and creates something great, is often seen in how companies work.
Some think that if you are busy and quiet, you are doing a good job. This makes developers wait to show their work until they think it’s perfect.
Also, some are scared to share early because they don’t want to seem like they don’t know enough. In some teams, people don’t trust each other much, or they only give/receive negative feedback. This makes developers not want to share their work early.
In all these scenarios, developers end up working alone, which can lead to the problems they want to avoid.
What are the implications?
In today’s world, we work as a team. Hardly any significant work (i.e. work that matters) is done by a single person. So it is important to ensure the code being written by someone goes well with the work of other people in the team.
When developers like Bob work in isolation for extended periods, their code often becomes an island by itself. Integrating such code with the rest of the project can be a nightmare. The longer the isolation, the greater the integration challenges, often leading to complex merge conflicts, incompatibilities, and sometimes, complete rewrites.
Isolated development can lead to blind spots in code quality. Without regular peer oversight, code may not adhere to best practices or team standards, leading to inconsistent quality in different modules. Issues like poor readability, lack of proper documentation, and technical debt can increase, making maintenance a Herculean task.
Like what happened to Bob, working alone can mean we make something that’s not what the team wanted. Without regular check-ins, developers might build features based on outdated or misunderstood specifications, leading to irrelevant or incorrect implementations.
Working with others can make your code better because you get new ideas and help. Collaboration and peer review are not only to find fault in some work, they are also about enhancing and optimizing code together.
Working alone can also have psychological effects. Developers may feel disconnected from the team, leading to a sense of isolation and ultimately decreased job satisfaction. Additionally, the pressure of having to deliver large chunks of code perfectly the first time can lead to burnout.
The longer the feedback loop, the harder and more costly it is to make changes. When developers work in isolation, feedback on their work is delayed, often leading to significant rework that could have been avoided with earlier intervention.
Techniques to break the silence
So far we have seen what programming in a cave mentality is and what are some of the reasons behind developers exhibit such behavior. At Comviva, we follow a holistic approach to reduce this effect as much as possible. It is given that it is often not eliminated, but we keep looking for scenarios and amend our process to create a truly collaborative team that works well together.
Regular Code Reviews
Our review starts as soon as there is some small but meaningful code available for any feature. A WIP (Work in progress)merge request is created to a feature branch and people are informed about the merge request. Interested people subscribe to the changes. One peer reviewer is assigned to it. Instead of an after-development big bang review, we prefer reviewing in chunks and smaller quantities, ensuring the quality of the review and the code is maintained properly.
The human aspect of the code review is given equal weightage.
Open and encouraging team environment
We believe it is OK to fail if we fail fast and then learn from it. Our reviews are focused on the artifact, and not the person. The comments given are aimed at making the solution better. Review is considered a two-way communication between the reviewer and the developer with only one goal in mind and that is to improve the quality of the artifact.
Continuous Integrations
Continuous Integration and code pipelines are set up within the development lifecycle. We want to ensure the newly committed code does not break the build or existing tests.
Regular Showcases and Feedback Cycle
We have established a regular showcase cycle with the product owner and other stakeholders to get early feedback on the feature being developed. Doing this regularly and with small chunks of sub-features enables us to check if we are building things as per market need and correct the course quickly if we deviate.
Similarly, when a requirement is demonstrated as a solution in front of the stakeholders they get a visual on the feature and it becomes easier to validate the thoughts quickly.
Use of proper tools in correct scenarios
With a mindset of automation first, this is important to have proper tools in place to promote faster feedback. Below are the tools we use for increased collaboration and to promote a faster feedback cycle.
Jira: Our user stories are tracked in Jira, and the team is encouraged to keep the sprint board updated. This gives some data on the capabilities of the team and provides visibility.
Gitlab: Our code is maintained in Gitlab. We follow an efficient branching strategy that helps us move things faster.
Peer Reviews: To ensure the code being written is seen at least by one pair of extra eyes, the concept of peer reviewer is introduced. As the person is at peer level, the environment is friendly and there is no judging of a person whatsoever. This ensures thorough discussions on the simplest changes to make it performant.
Lint Tools: As we work mostly on mobile technologies, we use Detekt and Swiftlint and integrate them into our workflows to ensure the code written is free of simple errors.
AI Code Review: Instead of an AI code reviewer, it is more like a code companion. We have set up one in-house portal that leverages the capabilities of Open AI’s GPT-3.5 Turbo and developers can get quick validation of their logic while doing development.
Slack: Slack is used as the primary communication medium. Sufficient slack bots are set up for gathering updates from the team. We strive to reduce meetings until they are really necessary and when we hold meetings we ensure the attendees are adequately prepared.
We are also exploring remote pair programming tools to enable people to work together. This is under experimentation.
In summary, we strive to ensure people are not working within silos and the environment is collaborative enough to get early feedback. For an organization that is shifting from a closed to an open environment, the changes can seem to be a little overwhelming, but with small and steady steps this mindset can be achieved.
This has several benefits, like better team collaboration, better product quality, quick feedback and iteration cycle, and finally, a situation where everyone learns and moves forward.
How do you ensure people work collaboratively in your organization? Do let us know in the comments.
Further watch: https://youtu.be/0SARbwvhupQ?si=lw8VerkFJ7Q89FcP
