Announcement

Sunday, October 13, 2024

Scale Changes Everything

 Originally Published on LinkedIn on 15th Oct 2024

One lesson I emphasize to my team is "Scale Changes Everything." Solutions that work for tens of items may not work for hundreds, and usually fail for thousands or more. This is a universal rule, not just in software.

Examples Across Contexts

  • Geographical Scale: Solutions that work in small European countries can fail when applied to larger countries like India or China (e.g., BRTS implementation in Pune).
  • Business Growth: Startups and companies often struggle to scale. Moving from tens of employees to 200-300 requires significant changes in ways of working. Growing beyond 1,000 employees necessitates rethinking tools, processes, procedures, and practices in finance, HR, and projects.

Technical Examples

  • Sorting Algorithms:
    • Algorithms for sorting 10 items (e.g., Bubble sort) do not work well for 1,000 items.
    • Algorithms for sorting 1,000 items (e.g., QuickSort) don't perform efficiently for 1 million items.
    • Algorithms for 1 million items (e.g., Merge Sort) may struggle with 1 trillion items.

Software Development Considerations

The question of scale arises at various levels:

  • Microservice vs Monolith:
    For a corporate application used by 200-300 users a day, a microservice architecture might be overkill, like using a Bofors gun to kill a mouse
  • Technology Choices:
    For a small startup with 10 people, using F# for fast development is fine.- However, if you plan to grow to 100 people, F# might be a poor choice since finding 100 developers proficient in F# can be challenging.

**We need a Mindset Shift**

Unfortunately, very few senior developers and software architects consciously think in terms of scale. They often blindly select a "microservice" architecture.

If the justification for a decision is "everyone is using it", then your company has a serious problem.

Wednesday, July 10, 2024

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

Wednesday, April 17, 2024

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.




Wednesday, April 03, 2024

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.


Tuesday, April 02, 2024

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.

Thursday, March 07, 2024

POSH Compliance or Workplace Safety

Since we started developing #ashure (https://www.ashure.in) and started talking with many companies, I often encounter companies that are only interested in complying with the law for the sake of avoiding penalties or lawsuits. They do not realize that POSH #compliance is not an end in itself, but a means to create a safe and respectful #workplace for all genders.

POSH law compliance is just one aspect of creating a "safe workplace". It does not guarantee that women or other marginalized groups feel comfortable and secure in their work environment. In fact, if there are zero POSH complaints in a company, the company management may feel Great but reason could be that women are too afraid or discouraged to report any incidents of sexual harassment or discrimination. This a false sense of 'achievement'. The HR department may think that they are doing a Great job in "outsourcing" POSH compliance to a consultant who dutifully fills all the necessary forms and policy documents. In reality, they are harming the company. Well, "road to hell is always paved with Good intentions"

On the other hand, if a woman raises a POSH complaint, then it indicates that she feel empowered and supported. It shows that the company has a good work culture and a relatively safe workplace. It also gives the company an opportunity to address the issue and prevent it from escalating or recurring.

I have heard comments from HR team members that promoting and displaying POSH policy and IC members names will invite a flood of complaints, even false ones, especially from the GenZ employees. Frankly This is a misconception and a reflection of their own bias and distrust towards their employees and the workplace culture. GenZ employees are not more likely to make false complaints than any other generation. In fact, GenZ are more emotionally mature and aware of their rights and responsibilities than the millennials.

The companies should not view POSH law compliance as a burden or a threat, but as an opportunity and a benefit. By creating a safe and respectful workplace for all genders, they can enhance their reputation, productivity, retention, and employee satisfaction.

Founders, Management Change your mindset, you will see big difference in your employees. Compliance with POSH law is NOT an expense or cost, It is #investment in your companies future.


#poshcompliance #safeworkplace #workplacesafety #ashure

PS> This post was originally published on LinkedIn