engineering-strategy – Shekhar Gulati

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.

Questions to ask when making Build versus Buy decision

Most software companies have to make decisions on whether to build a custom software or buy it from a vendor. Some of these decisions are mentioned below.

Should we build the recruitment tracking system or buy it?
Should we build a custom video KYC solution or buy an existing one?
Should we build a custom CRM or buy it?
Should we build a custom CMS or buy it?
Should we run your own CI server or use a cloud service like CircleCI?
Should we build our search engine using Solr or Elastic search or use a service like Algolia?

Questions To Ask When Choosing a Programming Language

This week I had a discussion with one of my friends on how to choose a programming language. It was triggered by multiple discussions I had with our customers on their engineering strategy in the last six months and one question that came multiple times was should we use X programming language for our new initiatives. Some customers were thinking of moving from .NET stack to Java, some banks were thinking about moving to Golang because their technical leaders have watched Monzo talks on Golang, for some it was from Java to Kotlin, and some were thinking of dumping JavaScript for Typescript.

To come up with the answer I try to find answers to following questions in context of the organization:

Defining Your Engineering Team Principles

In my current role as Chief Technology Officer (CTO), I am responsible for the engineering quality of our software delivery teams. We are an IT service organization where every now and then, we get to work with different kinds of customers in different domains and each at a different maturity level in software delivery.

One thing that I often struggle with is how to unite the individual engineering teams working for different customers with a common shared belief system that is actionable, pragmatic, and less abstract.

You may ask, isn’t that what organization values stand for? Before we answer, let’s define the three common terms: Values, Principles, and Practices.

My Thoughts On Monorepo

A monorepo is a software development strategy where a single version control repository has source code for multiple projects, libraries, and applications irrespective of their programming language. Also, the organizations using Monorepo strategy often use a common build tool (like Bazel, Pants, Buck) to manage all the source code. Some of the popular examples of organizations that employ monorepo strategy are Google, Facebook, Twitter, Microsoft, and Uber.

Before we start let me give some context on my background so that you can better understand my thoughts on Monorepo.

I head technology at an IT services organization. Most of the products that I build are using Microservices architecture, have multiple frontends(web and mobile). The biggest product that I recently built had close to 30 microservices, 1 web client written in React, and native mobile app built using React Native. These numbers are nowhere near the numbers big product companies have shared.

I prefer Macroservices over Microservices. I think most products don’t need more than 10 microservices.

How To Think About Platforms

In the last couple of months I was involved in a couple of consulting assignments where I had to understand the platform the team has built and give my recommendations. Platform is a broad term and it means different thing in different context.

Continue reading “How To Think About Platforms”