Best developers are developers following no rules

In the software industry, our pursuit of excellence often leads us to expand our knowledge both horizontally and vertically. We encounter well-established standards and principles such as Agile and SOLID, as well as Git branching models and other best practices. However, it’s not uncommon for us to deviate from these guidelines in our actual projects. This raises the question: Why do we sometimes choose not to apply these widely-recognized best practices, despite their origins in the collective wisdom of experienced individuals who have overcome challenges and devised these frameworks?

What motivates this departure from established norms and practices in software development? Are these best practices truly universally applicable, or do specific project requirements and contexts sometimes necessitate deviations from them? In exploring these questions, we can gain a deeper understanding of the nuanced decision-making process that takes place within the software development community.

It might sound reminiscent of the education system, doesn’t it? It operates effectively, but it’s not a one-size-fits-all solution. In the realm of software development, where problem-solving and creativity reign supreme, rigid adherence to rules often takes a backseat. We tend to gravitate towards what proves effective in our unique contexts and challenges, prioritizing practicality over strict adherence to conventional norms.

Allow me to share a story about the project I’m involved in. This project is managed by a team of three developers and 3 people from the client’s side, and interestingly, there is no dedicated tester on the team. We operate with two primary environments: Staging and Production. Our development process is rather straightforward — we write code, perform some initial testing on our local machines, and then deliver it to our client for testing on the Staging environment. Periodically, we release new features to the production environment, keeping our workflow streamlined and efficient.

Agile

While we embrace Agile principles, we’ve tailored our approach to suit our needs precisely. This includes planning and sprinting, followed by a comprehensive sprint review every two weeks. As for daily stand-up meetings, we’ve opted for a more streamlined approach. Instead of traditional meetings, we use ScrumGenius, an online tool that sends out a daily form to everyone at 9 AM. This method is both efficient and effective, so we’ve continued with it.

The pace of our project is crucial. We operate at a deliberate, slow tempo. We don’t require rapid feature releases; instead, we focus on delivering a select few new features while addressing maintenance tasks along the way.

Meetings aren’t a frequent occurrence for us; we find that sprint planning and sprint reviews suffice for our collaborative needs. While this might not seem ideal, our approach has proven effective. Our collaboration primarily takes place through regular chats, where we clarify matters without causing unnecessary disruptions. This system has been in place for over a year, and it works seamlessly. The result is a team where everyone enjoys the freedom to work independently, ensuring we don’t hinder each other’s progress.

We don’t physically go to the office at all. Our client is based in another country, making face-to-face meetings impossible. Instead, we hold bi-weekly Google Meet sessions for discussions. With just three developers remaining, the need for daily office meetings becomes redundant.

A project full of responsible people

When individuals take ownership of their tasks, there’s no need for constant oversight or progress tracking. Trusting in their commitment and dedication is key. In case challenges arise, we openly discuss them in our group chat, collaboratively seeking the best solutions.

Git branching model

The Git branching model is undoubtedly robust, but with just three developers on our team, it often felt like overkill. Two environments proved sufficient for our needs, as the process of merging and re-verifying code across multiple environments consumed significant time. To address this, we adopted a deliberate, slower tempo in our development process, prioritizing incremental updates and focusing predominantly on maintenance tasks. This approach instilled confidence in our ability to manage the workflow effectively.

Minimum technical requirements.

In the end, we achieved all of this by ensuring we had the right individuals in the appropriate roles. We set certain minimum requirements for team members. Deep technical knowledge and problem-solving experience were essential. Everyone had to be capable of working independently and thinking creatively. Having a fresher or junior team member would necessitate mentorship, potentially slowing down productivity and extending the adaptation period to the business and the technical intricacies of the project’s tasks.

Brief conversations are truly valuable; they maintain the team’s morale. Occasionally, we share light-hearted jokes about specific topics or engage in discussions unrelated to work. The key is to foster connections among team members, ensuring that no one ever feels overlooked or isolated.

Supportive

Recently, I needed to take a half-day off, so I requested that my teammate step in for me. We operate like close comrades, supporting each other when needed.

“i got your back, you got mine”

That’s how we keep our project running, what about yours?