The "Wheel Reinventor's Principles" advocate for strategically reinventing existing solutions, not out of ignorance, but as a path to deeper understanding and potential innovation. It emphasizes learning by doing, prioritizing personal growth over efficiency, and embracing the educational journey of rebuilding. While acknowledging the importance of leveraging existing tools, the principles encourage exploration and experimentation, viewing the process of reinvention as a method for internalizing knowledge, discovering novel approaches, and ultimately building a stronger foundation for future development. This approach values the intrinsic rewards of learning and the potential for uncovering unforeseen improvements, even if the initial outcome isn't as polished as established alternatives.
John Ousterhout contrasts his book "A Philosophy of Software Design" (APoSD) with Robert Martin's "Clean Code," arguing they offer distinct, complementary perspectives. APoSD focuses on high-level design principles for managing complexity, emphasizing modularity, information hiding, and deep classes with simple interfaces. Clean Code, conversely, concentrates on low-level coding style and best practices, addressing naming conventions, function length, and comment usage. Ousterhout believes both approaches are valuable but APoSD's strategic focus on managing complexity in larger systems is more critical for long-term software success than Clean Code's tactical advice. He suggests developers benefit from studying both, prioritizing APoSD's broader design philosophy before implementing Clean Code's stylistic refinements.
HN commenters largely agree with Ousterhout's criticisms of "Clean Code," finding many of its rules dogmatic and unproductive. Several commenters pointed to specific examples from the book that they found counterproductive, like the single responsibility principle leading to excessive class fragmentation, and the obsession with short functions and methods obscuring larger architectural issues. Some felt that "Clean Code" focuses too much on low-level details at the expense of higher-level design considerations, which Ousterhout emphasizes. A few commenters offered alternative resources on software design they found more valuable. There was some debate over the value of comments, with some arguing that clear code should speak for itself and others suggesting that comments serve a crucial role in explaining intent and rationale. Finally, some pointed out that "Clean Code," while flawed, can be a helpful starting point for junior developers, but should not be taken as gospel.
Summary of Comments ( 37 )
https://news.ycombinator.com/item?id=43434730
Hacker News users generally agreed with the author's premise that reinventing the wheel can be beneficial for learning, but cautioned against blindly doing so in professional settings. Several commenters emphasized the importance of understanding why something is the standard, rather than simply dismissing it. One compelling point raised was the idea of "informed reinvention," where one researches existing solutions thoroughly before embarking on their own implementation. This approach allows for innovation while avoiding common pitfalls. Others highlighted the value of open-source alternatives, suggesting that contributing to or forking existing projects is often preferable to starting from scratch. The distinction between reinventing for learning versus for production was a recurring theme, with a general consensus that personal projects are an ideal space for experimentation, while production environments require more pragmatism. A few commenters also noted the potential for "NIH syndrome" (Not Invented Here) to drive unnecessary reinvention in corporate settings.
The Hacker News post titled "Wheel Reinventor’s Principles (2024)" linking to tobloef.com/blog/wheel-reinventors-principles/ has generated a moderate number of comments, sparking a discussion around the merits and pitfalls of reinventing the wheel.
Several commenters agree with the author's premise, emphasizing the educational value of rebuilding existing tools and libraries. One commenter argues that reinventing the wheel is crucial for truly understanding how things work, leading to a deeper appreciation and ability to customize tools later on. They highlight the satisfaction and control gained from building something oneself. Another commenter concurs, suggesting that the process of reinvention, even if it doesn't result in a production-ready tool, fosters a valuable understanding of the underlying principles. This commenter even suggests that sometimes the act of reinvention can uncover hidden flaws or inefficiencies in the original design.
However, some comments caution against unnecessary or excessive wheel reinvention, particularly in professional settings. One commenter points out the potential cost implications and time wasted when readily available, well-maintained solutions exist. They advocate for prioritizing pragmatism and focusing on solving the actual problem at hand rather than getting sidetracked by reinventing tools. Another echoes this sentiment, asserting that while reinventing can be beneficial for learning, it's often more efficient to leverage existing resources, especially in a business context. They suggest that reinventing the wheel should be a deliberate choice made with awareness of the trade-offs.
A few commenters delve into specific examples of when wheel reinvention might be justified. One commenter mentions situations where existing solutions are overly complex or lack crucial features, making it more practical to build a simpler, tailored solution. Another commenter brings up the issue of licensing, arguing that sometimes reinventing is necessary to avoid using proprietary software or complying with restrictive licenses.
Finally, there's some discussion about the importance of knowing when to reinvent. One commenter proposes that reinventing the wheel is valuable early in one's career, but becomes less so as experience grows and the focus shifts to delivering value efficiently. Another commenter emphasizes the importance of thoroughly researching existing solutions before embarking on a reinvention project, ensuring that the effort is truly justified.