Know agile. Not habit. (जानामि Agile न च मे प्रवृत्तिः)

This is a work in progress. I am designing an event driven architecture to be used in systems using micro services. Micro service architecture is popular because it solves few problems in development process. While it solves some problems it also brings in new problems to the table. Bad designs impact micro services harder than monoliths. But this is thought is for another time.  How micro services talk to each other. In a monolith you have one gigantic database, or you can easily call another component to process the information. In a microservice you can use a Que (or event bus) to pass the information. This is the problem I want to discuss. Main issue with que is it is not designed for this scenario. There are few products which give a good solution by providing a subscription-based approach. But these are large implementations. Using these is similar to bringing an excavator to plant a sapling in your garden. Yes, many people go with using these large implementations to resolve thi

 When I began my career in software development, my architect advised me to adhere to the KIS principle. He discouraged me from implementing complex logic or using design patterns unless they were necessary. As a newcomer, I often tried to showcase my skills and leaned towards complexity. It wasn't until I gained more experience that I realized how challenging it is to keep things simple. Designing a simple system can be difficult, but it is also highly rewarding. What defines simplicity and complexity? The criteria for simplicity can be highly subjective. For example, writing a SQL query to obtain the top record in each category might be a straightforward task for one person, while another may find it complex. With experience and practice, we acquire skills that simplify tasks in our respective fields. However, there are certain areas that require careful attention, such as software teams. When a team is forming, it's best to keep things simple. Defining simplicity for a team

I heard a lot about ChatGPT and thought to come out of my cave to find out what the hype is about. Is it going to eat all my lunch or eat me for lunch?  Like any product I gave it all my details and signed up. I asked it about quantum computing an it gave some answer. So far so good. Next day I wanted to check its blogging skills. So I opened chatGPT and I got this . I checked throughout the day and it is still down. So it won’t eat me till it is fed few more servers.  Continuing after it was up.  I asked it to write a blog about itself. Here is what was generated by chatGPT.

Yesterday I made a statement to my daughter that she is spending too much time on the phone. She argued back that she is spending lots of time studying and uses phone for some relaxation from the hard work. How to solve the perception difference here. We need to measure the time spent on the phone. We also need to define what is acceptable ratio of phone and study. While I was not able to solve the perception battle there, it is easier on the work front. What do you want to measure in your team? I did list some measurement in a post ten years ago. And and Lion Fable I did not go deep into the why part at that time. Let us do it now. Without knowing why and what of the measurements you will become cargo cult agile   Team Velocity While estimation is not absolute, it still gives some visibility into the effort. If you want to know how much you can deliver, then you need to know your velocity. Without knowing velocity, it is a waste of time to plan. It will be a blunder to commit to a pla

We encounter issues in our work environments. Most of the time we just find a solution and move on. But some issues keep on repeating and need a deeper understanding. Some issues are significant and have a large impact on the business or on you. Such issues need to be dealt with in different ways. We need to find the root cause for these issues. It is always better to resolve the root cause than the symptoms of the problems. I often use the 5 whys method to perform RCA. This is simple and effective. Let us consider a simple example. Let us take an example from day-to-day life. Today I was driving bit rash and did some risky overtaking. That was really unnecessary. Let us check why I was putting myself in unnecessary danger? Why was I driving rashly? Cause: I was late for a meeting, Why was I late for the meeting? Cause: I woke up late. Why did I wake up late? Cause: I slept late yesterday. Why did you sleep late despite needing to be on time for the meeting? Cause: There was a

Agile manifesto defines first value as " Individuals and interactions over processes and tools". Is this value outdated? No. It is as relevant today as it was when the agile manifesto was signed. There are few finer details of the process we forget. We need to check the origins of different processes. Why should we care about the process that much? Mainly because the process takes time from productive work. When a process is a useless chore, it eats into the morale of the team. It is like termite eating and weakening your beautiful home. Same time it also eats into team time. Darwin wrote about natural selection and survival of the fittest. Unfortunately, natural selection in the process results in survival of bad policies. By the time bad processes are recognized, the company would have incurred significant costs. We can segregate processes into two broad categories based on how they originate. This can be validated by checking the value derived from each process and polic