This 1972 paper by Parnas compares two system decomposition strategies: one based on flowcharts and step-wise refinement, and another based on information hiding. Parnas argues that decomposing a system into modules based on hiding design decisions behind interfaces leads to more stable and flexible systems. He demonstrates this by comparing two proposed modularizations of a KWIC (Key Word in Context) indexing system. The information hiding approach results in modules that are less interconnected and therefore less affected by changes in implementation details or requirements. This approach prioritizes minimizing inter-module communication and dependencies, making the resulting system easier to modify and maintain in the long run.
Jazco's post argues that Bluesky's "lossy" timelines, where some posts aren't delivered to all followers, are actually beneficial. Instead of striving for perfect delivery like traditional social media, Bluesky embraces the imperfection. This lossiness, according to Jazco, creates a more relaxed posting environment, reduces the pressure for virality, and encourages genuine interaction. It fosters a feeling of casual conversation rather than a performance, making the platform feel more human and less like a broadcast. This approach prioritizes the experience of connection over complete information dissemination.
HN users discussed the tradeoffs of Bluesky's sometimes-lossy timeline, with many agreeing that occasional missed posts are acceptable for a more performant, decentralized system. Some compared it favorably to email, which also isn't perfectly reliable but remains useful. Others pointed out that perceived reliability in centralized systems is often an illusion, as data loss can still occur. Several commenters suggested technical improvements or alternative approaches like local-first software or better synchronization mechanisms, while others focused on the philosophical implications of accepting imperfection in technology. A few highlighted the importance of clear communication about potential data loss to manage user expectations. There's also a thread discussing the differences between "lossy" and "eventually consistent," with users arguing about the appropriate terminology for Bluesky's behavior.
The blog post "Common mistakes in architecture diagrams (2020)" identifies several pitfalls that make diagrams ineffective. These include using inconsistent notation and terminology, lacking clarity on the intended audience and purpose, including excessive detail that obscures the key message, neglecting important elements, and poor visual layout. The post emphasizes the importance of using the right level of abstraction for the intended audience, focusing on the key message the diagram needs to convey, and employing clear, consistent visuals. It advocates for treating diagrams as living documents that evolve with the architecture, and suggests focusing on the "why" behind architectural decisions to create more insightful and valuable diagrams.
HN commenters largely agreed with the author's points on diagram clarity, with several sharing their own experiences and preferences. Some emphasized the importance of context and audience when choosing a diagram style, noting that highly detailed diagrams can be overwhelming for non-technical stakeholders. Others pointed out the value of iterative diagramming and feedback, suggesting sketching on a whiteboard first to get early input. A few commenters offered additional tips like using consistent notation, avoiding unnecessary jargon, and ensuring diagrams are easily searchable and accessible. There was some discussion on specific tools, with Excalidraw and PlantUML mentioned as popular choices. Finally, several people highlighted the importance of diagrams not just for communication, but also for facilitating thinking and problem-solving.
The Canva outage highlighted the challenges of scaling a popular service during peak demand. The surge in holiday season traffic overwhelmed Canva's systems, leading to widespread disruptions and emphasizing the difficulty of accurately predicting and preparing for such spikes. While Canva quickly implemented mitigation strategies and restored service, the incident underscored the importance of robust infrastructure, resilient architecture, and effective communication during outages, especially for services heavily relied upon by businesses and individuals. The event serves as another reminder of the constant balancing act between managing explosive growth and maintaining reliable service.
Several commenters on Hacker News discussed the Canva outage, focusing on the complexities of distributed systems. Some highlighted the challenges of debugging such systems, particularly when saturation and cascading failures are involved. The discussion touched upon the difficulty of predicting and mitigating these types of outages, even with robust testing. Some questioned Canva's architectural choices, suggesting potential improvements like rate limiting and circuit breakers, while others emphasized the inherent unpredictability of large-scale systems and the inevitability of occasional failures. There was also debate about the trade-offs between performance and resilience, and the difficulty of achieving both simultaneously. A few users shared their personal experiences with similar outages in other systems, reinforcing the widespread nature of these challenges.
Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43244860
HN commenters discuss Parnas's modularity paper, largely agreeing with its core principles. Several highlight the enduring relevance of information hiding and minimizing inter-module dependencies to reduce complexity and facilitate change. Some commenters share anecdotes about encountering poorly designed systems violating these principles, reinforcing the paper's importance. The concept of "secrets" as the basis of modularity resonated, with discussions about how it applies to various levels of software design, from low-level functions to larger architectural components. A few commenters also touch upon the balance between pure theory and practical application, acknowledging the complexities of real-world software development.
The Hacker News post titled "On the criteria to be used in decomposing systems into modules (1972)" has a modest number of comments, sparking a focused discussion around the paper's core concepts and their relevance today.
Several commenters reflect on the enduring wisdom of Parnas's arguments. One user highlights the continuing struggle with modularity despite decades of progress in software engineering, suggesting that "we're still struggling to teach these lessons nearly 50 years later." Another emphasizes the importance of information hiding as crucial for managing complexity, not just in large systems but also in smaller projects.
The discussion touches upon the practical application of Parnas's principles. One commenter shares personal experience applying these ideas to a specific project, noting the resulting improvement in system maintainability. This anecdote provides a real-world illustration of the paper's theoretical concepts. Another commenter emphasizes the importance of "well defined interfaces" not just for modularity, but as a means to enable parallel development, ultimately speeding up project delivery.
A few comments delve into specific aspects of the paper. One user points out the importance of module cohesion and coupling as fundamental principles derived from Parnas's work. They highlight the interplay of these principles in achieving a well-structured system. Another commenter draws attention to the subtle but significant distinction between "hiding secrets" and hiding implementation details.
The discussion also explores alternative viewpoints and historical context. One commenter mentions the rise of microservices and how it relates (or perhaps contrasts) with the module decomposition principles outlined in the paper, questioning whether microservices truly adhere to these ideals or represent a different approach altogether.
While the discussion is not overly extensive, it provides valuable insights into the continuing relevance of Parnas's work and its impact on software engineering practices. The comments demonstrate a shared appreciation for the paper's core message while also acknowledging the ongoing challenges in applying these principles effectively in modern software development.