Useful Stuff I Read This Week

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

Who Is Driving the Great Resignation? – Link

It is hard to retain good talent in tech. I agree with the reasons on why employees are resigning in huge numbers. Shortage of good talent, better compensation, lack of purpose, burnout, career advancement are the reasons that I hear as well. One reason that I don’t see covered in the post is poor leadership skills. It might be implicit but I think it should be called out as well. Good leadership can provide a sense of belonging and purpose that can help retain good employees.

Continue reading “Useful Stuff I Read This Week”

Web API Design Anti-Pattern: Exposing your database model

One of the common Web API design anti-patterns that I see in the field is the exposure of database model in the API contract. If you are building a Java Spring Boot JPA application then it means exposing JPA entities as Web API’s request and response objects. The primary reason this happens is because most teams are not following contract first model of API design. They start from code and database schema and then they create API contract from them.

This is not the first time I have seen this anti-pattern being applied by development teams. I have seen this often so I thought let me document it so that in future I can share this post. The advantages of document such lessons/patterns/practices are:

  • I can be thorough in my explanation. Writing helps me understand if my point is valid. Writing is thinking for me.
  • While explaining to a developer I might forget a key point.
  • Give the development team time to reflect upon the feedback by themselves.
  • Discussion after going over the post might be more productive.
  • I can keep updating this post.

Following are the reasons that I think we should avoid exposing database model as an API contract.

Continue reading “Web API Design Anti-Pattern: Exposing your database model”

Useful Stuff I Read This Week

Here are 7 posts I thought were worth sharing this week.

Google: A Collection Of Best Practices For Production Services – Link

This is an amazing read. Building resilient systems is hard. The first step to building resilient systems is to become aware of the practices that are used in the trenches. All the practices are worth reading/knowing and you should look for opportunities to apply them in your environment . Every few weeks I see teams struggling with making configuration changes safely. Article gives some practice advice on the same. Writing fail-safe and resilient HTTP clients is not easy. HTTP clients are used heavily in Microservices architecture. Most developers consider the happy path when service either succeeds or fails with expected response codes. But, we need to consider retries with jitter, timeouts, queueing, load shedding, etc while building HTTP clients. This article covers a few more practices that can help us build resilient systems. 

Continue reading “Useful Stuff I Read This Week”

Playing with xbar: Showing WordPress Site Page Views In Menu Bar

Today while reading a tech newsletter I discovered xbar. xbar[1] lets you put output from any script/program in your macOS menu bar. Xbar is built using Wails. Wails[2] allows you to build desktop apps using Golang and Web technologies.

Xbar has a plugin based architecture. There are hundreds of pre-built plugins that help you view information about AWS, cryptocurrency, weather, date & time, and many others.

Continue reading “Playing with xbar: Showing WordPress Site Page Views In Menu Bar”

Useful Stuff I Read This Week

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

Talk: A History of Clojure – Link

Amazing talk by Rich Hickey on the History of Clojure. In this video, Rich covers how he took a two year self-funded sabbatical to build the first version of Clojure. Clojure is a dialect of Lisp, the second-oldest high-level programming language. Lisp is a functional programming language. He also covers challenges he faced to get the first customers, how he supported the community via email and IRC. I liked how he defined constraints for the languages and how he looked for practical answers to the real world questions related to performance. I have played with Common Lisp for a month or so while reading SICP. I will try Clojure soon as well.

Tips for High Availability – Link

This is a post from Netflix engineering team where they talked about how their CD practices enable high availability. Honestly, I was expecting to read more about system design stuff. Still, I enjoyed this post. They talked about things like blue/green deployment, deployment windows,canary testing, rollbacks, and few others. If you are into DevOps space for long you might already know most of them. I think the key about these practices is not knowing them but actually applying them at your scale. You really need a solid engineering culture to practice them. 

Continue reading “Useful Stuff I Read This Week”

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”