Architecturally Significant Decisions

Once again, I stumbled upon the documenting architecture decisions post[1] 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. 

Continue reading “Architecturally Significant Decisions”

Useful Stuff I Read This Week

Here are 10 posts I thought were worth sharing this week:

Mono-Repo vs One-Per-Service – Link

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.

Continue reading “Useful Stuff I Read This Week”

Doing Software Estimation within constraints of Hofstadter’s law and Parkinson’s law

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.

Continue reading “Doing Software Estimation within constraints of Hofstadter’s law and Parkinson’s law”

Useful Stuff I Read This Week

I am again starting a newsletter (sort of) with no expectations on its frequency. I will share links that I find useful and my short take on them. 

Coding in the Cloud with Codespaces – Link

Why codespaces:

  • On demand standard dev environments
  • Brings uniformity
  • Make software dev more accessible
  • Reduces friction
  • Enable quick experimentation

We have not commoditized dev. We have commoditized everything else.

Learn to think in sed, awk, and grep – Link

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.

Continue reading “Useful Stuff I Read This Week”

Podman for Java Developers: The Missing Tutorial

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 remains free 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.
Continue reading “Podman for Java Developers: The Missing Tutorial”

Playing with htmlq, awk, and sed

Last week I discovered htmlq, a CLI tool to extract content from HTML. It is similar to jq, a very powerful and popular command-line JSON processor.

The best way to learn a tool is to use it for something useful. In this short post, I am showing you how I used htmlq to extract content from my Github profile

Finding name of all the repositories on the first page

curl --silent\?tab\=repositories \
| htmlq 'a[itemprop="name codeRepository"]' \
| htmlq --text --ignore-whitespace \
| awk '{$1=$1};1' \
| sed '/^$/d'

It lists the last updated 30 repositories.

Continue reading “Playing with htmlq, awk, and sed”

On Reading, Creativity, and Self-Reflection

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. 

Continue reading “On Reading, Creativity, and Self-Reflection”

Why is it ok to write pass-through services in a Microservices architecture?

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.

Continue reading “Why is it ok to write pass-through services in a Microservices architecture?”