Old code, still running in production.

I follow  Allen Holub  in twitter and engage in some of his conversations. He believes it is possible to achieve full agility.  It does exist: SalesForce, Home Depot, Ford, Spotify, ING Bank, Zappos, Hunter, Petco, Shopify, Alaska Airlines, Tesla, Pluralsight, Peloton, even parts of IBM and Microsoft. I believe that you haven't seen it, but it's not a mirage. — Allen Holub (@allenholub) May 1, 2022 I think he is right and it is possible. Same time I also realized it is your mindset which needs to adapt to the agile working.  Let us for a moment forget the agile framework and think about business need. Change is part of life. In business too changes happen often. For a business to survive software needs to be in sync with the change to business. But the duration by which this sync should happen is different. If you consider a retail company, they do lot of sales campaigns. Their software should be ready for this campaign other wise they lose sales. But a company enga...

Many times in software development, we are not able to deliver on time. Everyone in the team works hard. But the team is not able to cross the hurdle and push the product to production. Everyone is stressed and worried. At some point blame game will start.  There is a novel written by Eliyahu M Goldratt called "The Goal". It introduces you to theory of constraints (TOC). It is a good read.  Let us take Inventory concept and apply it to software development. What is inventory in software development. All the work in progress (WIP) is inventory. When you hold lot of inventory your delivery speed is reduced. This is a proven fact in manufacturing and same is true in software development. All the WIP needs integration before product is complete. When number of WIP items increase integration becomes complex and takes lot more time. Another concept of interest is bottleneck. Even in software development there is bottleneck. Usually it is resource capacity. In some cases it is speci...

  I have designed and implemented many REST API's over years. If I have to do them now I would have chosen gRPC for more than half of those scenario's. REST (REpresentational state transfer) was developed early 2000's. It took off and replaced SOAP API's quickly. While gRPC is developed pretty recently in 2015. A quick comparison gRPC REST Uses HTTP/2 Uses HTTP/1.1 Protocol Buffer JSON or XML Limited browser support through proxy layer Universal browser support Client - response model.  Bidirectional support. Request - response model 7x faster If you do not consume the API's directly in your browser you should go gRPC. If your use case needs your browser to make API calls then REST is the option for you. I do not have the performance numbers of gRPC with a proxy like Envoy. I will update the article soon with that. All other aspects are comparable and give advantage to gRPC. If you want more details these are my references: gRPC vs REST: Understanding gRPC, OpenAPI ...

Common Integration approaches You can see these approaches used. File System  One application will write the data needed by others to file system. Consuming systems will read the data from file and process accordingly. This is probably oldest pattern used for sharing data between systems. This needs lot of maintenance. Both applications need to come to an agreement on when data will be written, when it will be consumed and who will manage the files. There is always a possibility of data corruption when it is in the file system. Human intervention is needed when there is a problem with the data. There is also a possibility of someone editing the file and change data.  Common Database Two applications share a common database. Or application will write to a common database or data warehouse. Data is read from the common database by other apps. This pattern is difficult to maintain. This can cater to few systems. The moment you add more applications complexity increas...