software-engineering complexity
The word “complex”, when used as an adjective, implies “consisting of many different and connected parts” and when used as a noun implies “a group or system of different things that are linked in a close or complicated way; a network”. Ant colonies, nervous system, public transportation systems of a country and software systems are examples of complex systems. The common denominator in all these examples is the interconnected nature of their parts. The reason for the interconnected nature of these systems is to deliver value. Complex systems allow distribution of tasks and responsibilities among its parts. Ant colonies leverage the complex nature for survival, achieved through the division of labour among the ants - such as finding food, maintaining the colony, and protecting the queen. The nervous system is a complex network of nerves and cells that allow your body to conduct various functions by carrying signals and messages to and from the brain to organs. Public transportation systems are complex networks of buses, trains, and trams that allow people and goods to move from point A to point B. Software systems are complex networks of code, data and infrastructure that allows a business or an organisation to deliver value to the user of their products.
leadership team-management
I have been very lucky this year to have been able to attend a very comprehensive leadership programme offered by my organisation. One of the sub-programs was the Authentic Leadership trainings, we went through a rigorous three days of discovering our leadership purpose. I was surrounded by a group of exceptional leaders going through the same process, all our core values were different, we were all unique people yet all of us had teams that believed in us, trusted in us. What was the common ground? Additionally, Why have I trusted and followed leaders in my organisation(s)? What makes them capture my trust? And, Why have there been a (smaller) bunch I have not been able to trust or follow?
effective-meetings facilitation leadership
Have you been in meetings where the group is trying to address a shared problem across more than one engineering team? Despite the shared problem, the meeting often gets derailed with no clear resolution or actions achieved. How do we allow valuable conversation in a safe environment? How do we leverage the frustration or energy of the room for greater good? How to ensure we keep on track and work towards clear actions/next-steps?
Posted on 28 Aug 2024
software-engineering design-patterns
DRY aka "Don't Repeat Yourself" was first coined in the book Pragmatic Programmer by Andrew Hunt and David Thomas. Here is the snippet from the book explaining the principle:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Why do we call it DRY?
DRY—Don't Repeat Yourself
"Don't Repeat Yourself" is just a short and punchy statement so it sticks around in the head. The principle is based on three clear callouts: Single, Unambiguous, and Authoritative.
DAMP aka "Descriptive And Meaningful Phrases", was coined by Jay Fields. He published a blog post comparing the two approaches and proposing that DAMP is required in scenarios where you are working with DSL. I want to widen the lens here a bit and propose that they are complimentary. DAMP emphasises being descriptive and meaningful, so does DRY on being unambiguous. Focusing on the intent they both want the intent of the outcome clear and self-explanatory.
extreme-programming test-driven-development software-engineering humble-object
I have been working on an internal firm CLI recently. This is written in dotnet 8, and I am using Spectre Console. Coincidence that I was writing my blog about My TDD Pilgrimage, and I was hitting rock bottom trying to test code I was adding in my Program.cs. What an irony. As I started asking around and also doing my research in parallel I came across the following 2 links: The links above provide comprehensive information about the humble object. Inspired by this, I rolled up my sleeves and started refactoring my code to make it more testable. Follow along as I first explain the pattern and then demonstrate, through a simple example, how you can refactor your own code to enhance testability. Together, we'll break down each step, making this concept easy to grasp and implement in your own projects.
Posted on 15 Jul 2024
extreme-programming test-driven-development software-engineering
In 2010, I was working at a startup and a colleague did a show-and-tell about unit tests. It was my first job, I had never seen unit tests before, and in all honestly, I completely disliked it. Initially, thought it was a waste of time. Today in 2024, I have a very unsettling feeling if I end up writing a code without writing tests first. I have always wondered why I had an allergic reaction at the beginning and why it took me the time it did to warm up to this practice. So I started to roadmap key milestones I had in the last 14 years and the agents that brought about this change for me.
architecture microservices service-oriented-architectures

In 2014, Martin Fowler and James Lewis put together a blog called "Microservices" after having concerns about the loose use of the term. I was working with ThoughtWorks at the time and, being a massive fan of Martin Fowler, I would always read his work. Although a decade has passed since then, and despite the clarity provided by his work and the community, the term 'Microservices' is still used loosely. There are definitely firms pioneering this architectural style, but many more are just following the trend for the sake of the name.

Ever since the term SOA was coined in 1996, there has been a lot of ambiguity surrounding it. In this blog, I am attempting to take a step back and explain what service-oriented architectures are and where microservices fit in. We will start by exploring SOAs themselves. Then I will move on to discuss the architectural styles sliced by sizes and finally examine the various implementation approaches based on functionalities. None of what I propose is new knowledge, it is an attempt to bring it all on a single page with the intent to form a reference for technical decision-making in organisations and teams.

software-engineering career-paths
As a software engineer, we are continuously learning and growing. With learning and growing, progress follows. Progress comes in the form of promotions, new roles and responsibilities, and sometimes even a change in the domain.
chaos-engineering resilient-systems
  • So you want us to break things on purpose?
  • You expect us to run this in production?
  • We have lots of pressing issues this is not a priority!
  • How is this different from DR testing? ...
feedback team-management leadership
Even though I have always practiced giving and receiving feedback regularly, I find every feedback session is unique. I tried drawing a mind-map by asking myself three simple questions: