Transforming a Struggling Software Team into a High-Performance Team - Part 3

In this  third installment of our series, "Transforming a Struggling Software Team into a High-Performance Team," we delve into the pivotal third step of our transformation: improving our version control practices.

Our team's journey with Git, took a dramatic turn as we shifted from the somewhat chaotic 'developer branches' to the harmony of a unified 'trunk' based development approach. This strategic move was not just a change in process, but a cultural shift towards collective code ownership and streamlined workflows for a typical small to medium-sized team.

The creation of two  branches, 'develop' and 'bugfix', from the 'main' branch, marked the beginning of a new chapter. Developers merged their individual efforts (i.e. the individual 'developer branches' into the single 'develop' branch, resolving any conflicts along the way, and then bid farewell to their isolated 'developer branches'. This unification meant that all developers were now committing directly to the 'develop' branch, fostering an environment of collaboration and immediate integration.

To ensure a seamless workflow, we introduced critical practices such as syncing with the latest code at the start of the day and post-lunch, as well as pushing changes before breaks. This routine not only kept each developer codebase fresh but also minimized integration headaches.

Our build strategy also saw a transformation with the introduction of a daily build from the 'develop' branch, a QA build from the 'bugfix' branch for our diligent testers, and a customer release build triggered upon merges to the 'main' branch. This structured approach led to a more stable codebase, with integration issues being swiftly identified and rectified during local feature testing.

Join us as I continue to share this journey in the quest to achieve software excellence. Stay tuned for more insights and strategies that can help transform your team from struggling to high-performing.

Elevating our software team's game, we've changed our version control protocols, catapulting code stability to new heights. Developers now unearth and rectify integration snags swiftly through meticulous local feature testing. We've instituted  release naming conventions, build number tracking, and a streamlined hot fix process. This strategic overhaul has slashed the influx of trivial bugs to QA, empowering our engineers to zero in on pivotal feature and behavior anomalies. The result? A seismic reduction in customer-facing bugs, showcasing our commitment to excellence. (P.S. These insights are versatile, meshing seamlessly with any version control system, be it Subversion, Mercurial, or Perforce.)

NOTE :  This article was originally posted on LinkedIn and expanded.

• Part 1 of this series
• Part 2 of this series

Transforming a Struggling Software Team into a High-Performance Team - Part 2

 🚀 Transforming a Struggling Software Team into a High-Performance Team - Part 1 

One Proverb all project managers and tech leads should member is _"Road to Hell is Paved with Good Intentions"._ But in software development, Good Intentions can also lead to a maze of bugs." This is a mantra that every project manager and tech lead should remember. Implementing a policy with good intentions does not guarantee positive outcomes for your project.

Take the common practice of using try/catch blocks in Java and .NET projects. Developers often add these blocks intending to prevent crashes. However, if the catch block merely logs the error and the exception is not properly handled, it can create chaos for the entire team.

Let's dissect a hypothetical scenario to highlight the issue:

x = func1();
y = func2(x);
z = func3(y);

In an ideal world, if  `func1()` throws an exception, neither `func2()` nor `func3()` should be called. But what if a developer wraps `func1()` in a try block followed by an empty catch block? The exception is caught, and the program erroneously proceeds to `func2(x)`, operating on a potentially incorrect or corrupted state of 'x', which could lead to another exception. To "fix" this, another empty catch block is added, and the cycle continues until `func3(y)` crashes.

The real bug, however, likely resides in `func1()`. This means the developer will waste a significant amount of time tracing back to the actual cause of the problem.

As a Tech Lead, by advocating a 'no-crash' policy without proper exception handling, you've inadvertently constructed a 'road to bugfix hell'. It's a cautionary tale that underscores the importance of thoughtful and effective error management in software development. 

Lets get back to our Case study of  "Transforming a Struggling Software Team into a High-Performance Team"

Imagine a codebase, a labyrinth of about 500 try/catch blocks, most leading to dead ends of empty catch blocks. This was the daunting maze the "Struggling Software Team." was working with. Determined to bring order to chaos, I (along with Project Manager and Team lead) championed a cleanup crusade. The result? A leaner, meaner set of 50 catch blocks, each a sentinel effectively guarding against errors, no longer just placeholders but active defenders of code integrity.

The moment of truth came when `func1()` threw an exception. Instead of the usual obfuscation, what emerged was a crystal-clear call stack, pinpointing the 'correct' error. This clarity was win for the developers, project manager and technical lead, This singular fix slashed bug fix times from a sluggish weeks to a swift days.

This narrative isn't unique. Many software teams, with the best intentions, erect barriers to their own success. Intelligent teams risk devolving into dysfunction, not for lack of skill, but from practices that stifle rather than stimulate productivity and quality.

The linchpin in this equation is the project manager and the management team. I've witnessed customers miss out on significant productivity and quality gains simply because these practices weren't taken seriously, weren't enforced. The cost? Not just in subpar productivity and quality, but in the ballooning development costs that inevitably follow.

Join the conversation and share your experiences in transforming software development practices. Let's inspire and learn from each other's journeys.

Transforming a Struggling Software Team into a High-Performance Team

 NOTE : The short version of this article was published on LinkedIn on 30th March 2024

🚀 Case Study: A Remarkable Turnaround in Software Development

In February 2024, I was approached by a leading Indian Software MNC grappling with significant challenges in one of their project group. The issues were critical: persistent bugs, delayed schedules, and plummeting productivity. The customer dissatisfaction was palpable, with bug reports coming in and the team's fixes lagging behind, taking an average of 3 to 5 days for each bugfix.

The project was not that big, with Java code ranging between 30K to 40K lines. It was clear that a strategic overhaul was necessary.

🔍 My first step was a thorough review of the team's code and development practices. What followed was a series of targeted interventions:

• Revamping coding practices
• Integrating a static code analysis tool into the build process
• Streamlining the development workflow

The results? Within a mere 6 weeks, the turnaround time for bug fixes was reduced to just one day. All critical issues, including a longstanding bug, were resolved. And the most impressive part? It was achieved with the same team, whose potential was unlocked through improved practices and processes, backed by the unwavering support of the Tech Lead and Project Manager.

Throughout my career, I've witnessed this scenario repeatedly: talented and diligent software engineers hamstrung by inadequate coding and development practices. The solution is straightforward yet transformative—refine these practices, and watch the same team perform miracles.

Stay tuned for my upcoming blog article detailing the key practices that can elevate your development team's productivity and quality.