Bits, Bytes, and Bylaws: Timeless Computing Laws (Part - 2)
From Whimsical to Principled: The Laws of the Computing Realm
Brook’s Law (Fred Brooks)
Adding manpower to a late software project makes it later.
In the world of software development, contrary to the knee-jerk 'managerial reflex'’ adding more manpower to a delayed project is like adding fuel to the fire. It's a classic scenario: new developers need time to get up to speed, during which the whole team often slows down. By the time everyone's on the same page, you've got more overhead and even slower progress. It's the project management equivalent of a traffic jam caused by everyone rushing to work at the same time.
You may ask why there is low productivity even after time has passed. Let me quote the reasoning from one of my favorite books.
For every additional order of magnitude of engineers, you need to design and maintain a new layer of management.
For every ~10 engineers, you need an additional team, which requires more coordination.
Each engineer means more commits and deployments per day, creating load on your development tools.
Most outages are caused by deployments, so more deployments drive more outages, which in turn require incident management, mitigations, and postmortems.
Having more engineers leads to more specialized teams and systems, which require increasingly small on-call rotations so that your on-call engineers have enough system context to debug and resolve production issues. Consequently, relative time invested in on-call goes up.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 46). Stripe Press. Kindle Edition.
Goodhart's Law (Charles Goodhart)
When a measure becomes a target, it ceases to be a good measure.
In the programming world, this could be rephrased as, "When you start playing 'hide and seek' with metrics, the true goal hides really well."
Take the classic scenario where developers, in an effort to outsmart SonarQube's linting errors, end up creating variables like ONE_TWENTY_NINE. It's like renaming your pet cat 'Dog' to avoid pet restrictions in your apartment.
This creative workaround to suppress linting errors is a perfect example of Goodhart's Law in the wild. Developers are so focused on improving the metrics that they end up playing a game of numerical charades, where the `magic number` 129 becomes ONE_TWENTY_NINE, and code quality becomes an afterthought. It's a bit like putting lipstick on a pig – the pig isn't fooled, and neither is the code.
Conway's Law (Melvin Conway)
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
This is Conway's Law, and it's like saying if you're a company that communicates via carrier pigeons, don't be surprised if your software feels a bit... feathered.
Take Amazon with its two-pizza teams, and SOA or microservices, and micro frontends. These aren't just tech choices; they're reflections of Conway's Law. It's like saying your org chart maybe your architecture diagram too.
Then there's the "Reverse Conway Maneuver," where smart managers can get crafty and reshape their teams to influence the software's architecture. Need certain modules to stay independent? Keep those team cubicles so far apart they need a map to find each other! But where modules need to interact closely, the teams should be cozy neighbors, maybe even sharing a coffee machine. It's a bit like matchmaking in the corporate world – ensuring the right teams are in the right relationship for the software to flourish.
This dance between organizational design and software architecture suggests that sometimes, the most powerful tool in a software developer's kit might just be the company's HR layout. So, the next time you see a convoluted piece of software, remember, it might just be a reflection of the company's love for labyrinthine org charts.