A naukri.com initiative
Ubuntu
2d
93
Paul Tagliamonte: Complex for Whom?
- Complexity is a common topic of discussion within high-functioning engineering organizations. Rarely, however, is it talked about within its appropriate context: complexity for whom?
- For instance, is something complex for the end user, an API consumer, or simply the person maintaining the API service?
- Complexity within a problem domain is, more or less, zero-sum. The problem to be solved comes with a fixed amount of complexity, and it must be decided who should solve it.
- There is an upper bound to the complexity of solutions possible. Teams often create problems for themselves while trying to solve a problem.
- Complexity within an organization leads to hyperspecialization, where priorities diverge, and efficacy is measured by each specialist's ability to solve the subset of the organization's problems.
- Lower limit complexity can't always be removed without introducing additional complexity elsewhere. It's a tradeoff that must be considered within the full context.
- Within technical mandates, decision-makers optimize for the least amount of complexity, offloading it through mandates into accreditation and risk-acceptance functions.
- Complexity is not the same as proclivity to failure. The most reliable systems are often unimaginably complex, with layers of internal protection to prevent complete failure.
- When someone talks about all the complexity about to be introduced, it's essential to understand their perspective and what type of complexity they are referring to.
- It's important to ask whether the perceived complexity should be solved elsewhere, whether it's desirable, or whether it affects others internally or externally.
Read Full Article
5 Likes
For uninterrupted reading, download the app