Hacker News new | past | comments | ask | show | jobs | submit login

Reading "The Goal" and contemplating how to apply the Theory of Constrains to complex software systems a couple of decades ago became part of the secret sauce of my career as a software engineer. Especially helpful was the insigth that one may make good progress tuning one part of a system only to discover that a larger constraint prevails as the true bottleneck.

Here's a practical example. For those who may still wrangle fleets of actual cloud instances (instead of going the managed cluster or serverless route), a common mistake is to imagine that all that is needed is a group of the smallest compute units available. But with AWS, for example, this can bite you when the smallest instances also have dinky allowances for network and/or disk I/O compared to medium or larger instances. People end up wondering why their queues aren't draining quickly or their DB writes or log pipelines are backing up, etc.




> one may make good progress tuning one part of a system only to discover that a larger constraint prevails as the true bottleneck.

In my latest job this was exactly the case. We were modernising a good old big ball of mud. And we made very decent progress on a part that was supposed to read from an API. That was nice but turned out that the API itself is poorly designed, and the vast majority of problems and slowdowns are coming from the other side. And the true bottleneck was that the team responsible for data was not very well prepared, so there was little design, poor coding, etc. And what really turned out to be the bottleneck is that the entire department just has a problem with processes and with hiring and retaining qualified people, and with ups killing the existing ones ...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: