Once again, I stumbled upon the documenting architecture decisions post by Michael Nygard. This time, a particular line from his post got me thinking and made me dig a little deeper into the subject. The line said, “ ‘architecturally significant’ decisions [are] those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques.” The reason this piece of statement is important is because most of the time architects are not clear about what they should document.
The author suggests that we must document architecturally significant decisions. He divides them into five categories. In the post, he does not give examples against those categories, so, I am taking the liberty to add mine.
Below is my interpretation of these categories. It could be different from the author’s intent.
I prefer Monorepo over Polyrepo(one repo per service) approach. The author made a good point on the cost of monorepo rising steeply once your team size reaches 100~150 developers. Author suggests that you can start with a monorepo and if your development team velocity starts to take a hit because of code organization then you can split the monorepo into multiple repositories.
I work in an IT service organization where the biggest project that we do has 50-70 developers. After deliberating a lot I have started using the following structure. So, in my setup I have 4 git repos. Consider a team of 50 developers, none of the repos cross more than 25 developers working on a single repo. I have shared my thoughts on Monorepo here.
How To Rapidly Improve At Any Programming Language – Link
This makes sense. Reading closed PRs of an open source project can be a valuable source of knowledge. I might give it a try as well. I tried doing code reading earlier when I went over code of popular open source library Retrofit and blogged about lessons I learnt.
There are two popular adages in software development that people use when talking about software estimates.
Hofstadter’s law states that it always takes longer than you expect, even when you take into account Hofstadter’s Law
Parkinson’s law states that work expands so as to fill the time available for its completion.
Hofstadter’s law suggests that you will always underestimate even if you add a buffer. On the other hand, Parkinson’s law suggests that if you give more time to a task it will take more time to do it. In short, we are doomed either way. So, let’s not do any estimates. #noestimates FTW! The reality is that all customers will ask you for estimates and timelines before they award you with a project.
Estimates are required for:
Making a business case for the new project;
Knowing when the project will be delivered;
Allocating money or teams of people for some amount of time;
Working backwards from the end date.
One of the least favorite parts of my current role is to provide estimates for new software development project bids. In this post, I will not be talking about sprint estimates or release/milestone estimates. Instead, I will talk about product development projects. These usually involve uncertainty, ambiguity, and customers not sharing/knowing complete details. Examples of such projects include a new mobile banking application, omni channel customer onboarding insurance app, a back office customer 360 degree platform, oracle to postgresql migration (involves stored procedures as well), reengineering a mainframe based pricing engine to modern real-time pricing engine, and many others. As a side note, I also actively participate in their architecture and solutioning.
Learn how to do text processing with sed, awk, and grep
Why you should be deploying Postgres primarily on Kubernetes – Link
Covers many reasons why you may want to run Postgres on Kubernetes. Reasons include production ready configuration, connection pooling, automated backup, monitoring, high availability setup, and few others. Also, it talks about an interesting project called Stackgres that automates all of that. With a few lines of YAML you can have your full setup automated and running on Kubernetes in less than an hour.
I have been using Docker since late 2013 and for me and many others Docker has revolutionised the way we build, package, and deploy software. As a community we are grateful to Docker and its creators. Docker is one of the first tools that I install on my dev machine. It used to be always running on my MacBook and anytime I wanted to try a new technology I preferred to install it using Docker. Just do a docker run <tech> and you are good to go. But, this has changed in the last couple of years. Docker for Mac is still installed but I no longer keep it running. The main reason for that has been the amount of resources it consumes, distracting fan noise, and MacBook becoming too hot. There are many issues filed in the Docker for Mac issue tracker on Github where developers have shared similar experience. Still, I kept using it as there was no good alternative available.
A couple of weeks back I learnt that Docker has changed its monetization strategy. Docker Desktop (Docker for Mac and Docker for Windows) will soon require subscription. From the Docker blog published on 31st August 2021 I quote:
Docker Desktop remainsfree for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
It requires a paid subscription (Pro, Team or Business), starting at $5 per user per month, for professional use in larger businesses. You may directly purchase here, or share this post and our solution brief with your manager.
While the effective date of these terms is August 31, 2021, there is a grace period until January 31, 2022 for those that require a paid subscription to use Docker Desktop.
This week I had an interesting discussion with a close friend. We have known each other for more than twenty years and whenever we see each other we ask each other what we have learned since we last met. This one question leads to many other questions and we spend many hours discussing different aspects of life and work.
This week I had a discussion with one of the developers in my organization on pass-through services. A Pass-through service is a service that wraps an existing service without much logic. Its job is to delegate to the downstream service. The existing service could be legacy service or an external third party API. The developer was questioning the purpose of pass-through services and the amount of development effort that goes in writing and maintaining them. In this post I am sharing the reasons that I gave to the developer to help him understand why pass-through services are not a bad idea and they can be helpful in the long run.