Stop Abusing try/catch. Its Killing Your Productivity

I once joined a consulting project where the team was drowning in bugs. Fixes took 3–5 days, customers were frustrated, and developers felt stuck.

As I reviewed the code, the culprit became obvious: 500+ try/catch blocks scattered everywhere. The mindset was simple -- "It shouldn't crash"

But here’s the irony: crashes are the easiest bugs to fix. They give you a call stack, a direct pointer to the problem. Wrap everything in try/catch, and you don’t prevent crashes—you hide them. The program keeps running in an unstable state, leading to silent data corruption and endless debugging nightmares.

I pushed the team to delete unnecessary try/catch. We went from 500+ blocks to ~50. The impact was immediate: bug turnaround dropped from 3–5 days to just 1 day. Customers were happier, and the team felt empowered again.

Stability doesn't come from hiding crashes. It comes from facing them head-on

Here’s how you can start:

1. Delete try/catch in private/protected methods. Keep them only in public methods.
2. Remove catch-all blocks (catch(...), catch(Exception)) everywhere except at the very top of your app.
3. Replace null checks with proper contracts: @NotNull in Java, assert in C++/others.
4. When a crash happens (during development or during testing), analyze the call stack and fix it at the highest level possible.

Make these changes and watch your team's debugging speed and delivery timelines skyrocket.

Published on LinkedIN on 24th Nov 2025

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.

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