Posts

Why Test Nomenclature matters for Engineering Leaders

Image
Introduction As leaders overseeing engineering teams, one of your core responsibilities is ensuring that development processes are efficient, scalable, and aligned with business goals.  Testing , though often seen as a technical task, plays a pivotal role in these objectives. Misalignment in testing practices and unclear definitions of testing terms can result in inefficiencies, delayed releases, and a loss of trust within teams. In this post, we’ll explore why creating a  shared vocabulary around testing nomenclature  is not just a tactical necessity, but a strategic investment that affects your organization’s ability to deliver fast, reliable software. What’s in a name? Myriad of software testing tactics A quick online search will show just how many terms exist for different testing types or tactics – end-to-end tests, regression tests, contract tests, smoke tests, and more. Without context and consistency, the implementation and purpose of these tests are left to interpretation. For

Decision-Making, Simplified: Async LDRs (Part 3)

Image
  Introduction In the  first  and  second  posts, we explored the key aspects of Lightweight Decision Records (LDRs) and how to leverage them for decision-making. LDRs help teams document and structure their decisions with clarity, visibility, and alignment. In this final post, let’s dive further into the async aspect of LDRs, where decision-making occurs over time ( akin to eventual consistency in distributed computing ), not in real-time, unlocking structured decision-making in remote and distributed teams. Embracing Asynchronous Communication The modern workplace is increasingly decentralized, with team members spread across different cities, time zones, and even working hours. Traditional decision-making often relies on synchronous communication, like online meetings and real-time discussions. While these methods have their place, they can create bottlenecks for distributed teams, especially when coordinating across time zones or busy schedules, leading to delays and misalignment.

Decision-Making, Simplified: Async LDRs (Part 2)

Image
Overview In the  first part  of this series, we explored the concept of Lightweight Architecture Decision Records, and their evolution into Async LDRs. We also uncovered the key dimensions of a decision that should be captured in a LDR. Another crucial aspect of a decision record is its  template . As you may know, a template means a pre-formatted file which makes it easier to create associated documents, and is often supported with tooling options. In our context, the more lightweight, accessible, and contextual the  ADR Template  is, the higher is the longevity of the associated ADRs. Also, ADR / LDR / Async LDR Templates are structurally equivalent, with the semantic differences being context (technology, process or people) or communication mode (sync or async or mixed). Authoring a LDR If your team is considering this technique, I would recommend starting with a meta decision: “ Decision-making strategy for Team Awesome ” (or equivalent). While this meta activity may sound trivial,

Decision-Making, Simplified: Async LDRs (Part 1)

Image
From impulsive choices to paralyzing overthinking, we all grapple with it.  This post shares my journey in developing a structured approach to decision-making, called  Asynchronous Lightweight Decision Records (Async LDRs) .  Specifically applicable for large / remote teams, Async LDRs can enhance accountability, collaboration, transparency, and collective ownership in decision-making. My journey In 2016, inspired by a mention of  Lightweight Architecture Decision Records  in the Thoughtworks Tech Radar, a colleague and I set out to pilot it in our client project to document their technology evolution and its current landscape. It turned out to a be a low-effort, high-impact solution, since it improved the team morale, moved the needle for technology adoption, and became a key asset in onboarding of new team members effectively. In 2019, I was part of a squad which was driving legacy modernization and engineering effectiveness for a client. Here, I adapted this technique to cover proce

WPF - Navigation

Image
Premise Over the past few weeks, I was scrambling to develop a WPF 4.0 application along with a UI designer who specializes in Expression Blend. Though I have worked on WPF 3.5 projects previously, I was really flummoxed while implementing fundamental portions like navigation, modal pop-up’s, “Loading” animation, session management, etc. in WPF. I am not saying that WPF 4.0 is vastly different from WPF 3.5, but I realized that I have never closely worked with XAML and WPF specifics like dependency properties, resource dictionaries, routed events, etc. Anyway, since I had very limited time, I mostly chose the easiest ways to implement specific areas of the application. In this post, I will describe the simplest method to implement navigation in WPF. Disclaimer You might have come across WPF architectural frameworks such as PRISM, MVVM, etc. I have some experience with PRISM, but for my current application, I needed a "very very basic” navigation mechanism. So I woul