Elevating DevOps: A Journey from novice to Master craftsman

 In the dynamic world of DevOps, the gap between theory and practice can sometimes seem as vast as space itself. Reflecting on my journey through countless interviews with DevOps engineers, a pattern emerges: a disconnect between claimed experience and practical knowledge. It's a concerning trend that sees the essence of DevOps, a craft of precision and innovation, being diluted by superficial engagement.

Rewind to the days before DevOps became the industry buzzword. I was at the helm of creating a comprehensive DevOps platform for Geometric Ltd., integrating both commercial and open-source tools. This experience was more than just 'clicking buttons'; it was about architecting a seamless workflow that propelled projects forward.

For those aspiring to master DevOps, here's a distilled essence of my experience:

1. Begin with the roots. Watch John Allspaw and Paul Hammond's seminal presentation at the Velocity 2009 conference. Let it be your DevOps genesis, and absorb its insights multiple times.
2. Dive deep into Version Control Systems (VCS). Whether it's Git, Mercurial, or Subversion, understanding the intricacies of VCS is non-negotiable. They are the backbone of any robust DevOps strategy.
3. Ensure everything is traceable. From source code to CI/CD configurations, every element should be version-controlled, allowing you to pinpoint changes with precision.
4. Immerse yourself in the wisdom of pioneers. My recommended reads include 'Release It' by Michael Nygard, 'The Phoenix Project' by Gene Kim, and 'Accelerate' by Gene Kim and Jez Humble.
5. Learn from the best. Study the engineering blogs of tech giants like Netflix, Google, and Facebook, Uber to stay abreast of cutting-edge practices.

DevOps is not just a role; it's a mindset of continuous improvement and relentless pursuit of excellence. Let's commit to upholding the true spirit of DevOps and nurturing the next generation of software craftsmen. 

Posted on LinkedIn  https://www.linkedin.com/posts/activity-7215942686271238144-7XjI

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.