Tech

If you haven’t been living under a rock in the past months, then chances are you’ve probably heard of the global “Blue Screen Of Death” (BSOD) incident caused by CrowdStrike. Interestingly, they've been receiving criticism for breaking one of the most commonly known rule in software development: don't deploy on Fridays. But could they have prevented one of the largest global software-induced outages if they didn't deploy on a Friday? I don't think so.

Speed is critical to business success, where delivering too slowly can result in a business losing its competitive edge. Some of the most successful people I’ve worked with, the ones who you just know can thrive in any business, all have this one particular characteristic (or skill?): to be able to discriminate and know when one can move fast and when one can’t, and isn’t afraid to face uncertainty head-on and move fast when they can. I believe that this is attributed to having a strong culture that embraces iteration and continuous improvement. Below, I share some of my perspectives on areas you can focus on to foster, strengthen, and embrace to integrate iteration and continuous improvement into your company culture.

Recently I’ve had the luxury to encounter and resolve a production NodeJS memory leak in one of my current companies NodeJS applications. In this blog post, I discuss 3 key takeaways and lessons I’ve learned from this experience.

The first part of many(?) blog posts curating my observations and opinions of podcasts I listened to or blogs I’ve read regarding software management practices. In this blog post, I discuss using product/software requirements and when it’s appropriate to use an agile vs a non-agile approach.

Imagine a perfect world, where you have an unlimited amount of time to produce quality software without ever needing to cut corners and incur any technical debt. Unfortunately, such a world is unrealistic, and in most cases, you or your team will have to incur tech debt whether you like it or not. What’s important is to be pragmatic and considerate when approaching technical debt and instead of focusing on being “tech debt free forever”, we should focus on answering questions such as “when is it appropriate to avoid tech debt in favour of delivering faster?”, and “how should we prioritise tech debt in conjunction with other items on the product roadmap?”

I admit it, realistic time estimations and on-time delivery was something that I (and probably many of us) could never get quite right. These are some lessons I've learned to provide more accurate time estimates and ensure on-time delivery.