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.