6 ms·

This is a parable about whether you really understand the nature of the problem, or not. If you do then you can produce a concise definition (i.e. a better prog

by motters 12y ago

This is a parable about whether you really understand the nature of the problem, or not. If you do then you can produce a concise definition (i.e. a better program in fewer LOC) and if you don't then it can get much more complex. It's like the difference between trying to make a machine fly by making wings out of feathers and having it flap, or understanding the principles of aerodynamics and making a fixed wing out of canvas. However, for most non-trivial problems understanding everything up front isn't possible. To know what works you may need to create prototypes and iterate, abandoning things which don't work or which end in a hairball of complexity and getting opinions from testers. In that situation just intuiting a solution and then typing in the code won't work and the more formalised process might work better.

TheOtherHobbes 12y ago
The parable is really about the nature of corporate politics and the art of perception management. I'm not sure how obvious the underlying point is -> programming languages and methodologies are structured by political requirements. Programmer A is writing software. He knows nothing about perception management and status plays. Programmer B is furthering his career and angling for a raise. By accepting 'corporate coding standards' he has proven he knows how to play the game and uses the project to increase his status. The quality of the finished product, in terms of user experience and practical usefulness, isn't nearly as important as the social processes that created it. IMO the interesting question is how much this applies to coding culture and language and OS design as a whole.
marcosdumay 12y ago
> However, for most non-trivial problems understanding everything up front isn't possible. You know, people keep saying that, but I'm yet to find one example of it on real life. Yes, there are contexts with many rules, but I never found one that you couldn't modularize into person-sized problems. That said, for several times I've solved in a month or two (took six once) problems that other people struggled with for years in the "corporate way" of development without any kind of success.

by motters 12y ago

TheOtherHobbes 12y ago

The parable is really about the nature of corporate politics and the art of perception management. I'm not sure how obvious the underlying point is -> programming languages and methodologies are structured by political requirements. Programmer A is writing software. He knows nothing about perception management and status plays. Programmer B is furthering his career and angling for a raise. By accepting 'corporate coding standards' he has proven he knows how to play the game and uses the project to increase his status. The quality of the finished product, in terms of user experience and practical usefulness, isn't nearly as important as the social processes that created it. IMO the interesting question is how much this applies to coding culture and language and OS design as a whole.

marcosdumay 12y ago

> However, for most non-trivial problems understanding everything up front isn't possible. You know, people keep saying that, but I'm yet to find one example of it on real life. Yes, there are contexts with many rules, but I never found one that you couldn't modularize into person-sized problems. That said, for several times I've solved in a month or two (took six once) problems that other people struggled with for years in the "corporate way" of development without any kind of success.