tag:blogger.com,1999:blog-3524127.post3096084961646027619..comments2023-10-27T01:20:31.352-06:00Comments on IdeaJoy: SAIT - Three InukshuksUnknownnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3524127.post-50692656735085224352014-09-12T08:11:43.926-06:002014-09-12T08:11:43.926-06:00Hi Paul. Sorry for the late reply.
The answer ...Hi Paul. Sorry for the late reply. <br /><br />The answer to your question is of course it depends a great deal on context. How published is the code, internal IT code vs the JDK code? <br /><br />In terms of values and where you put your effort first as a default. Code readability is first and foremost to me. <br /><br />Meta data such as lifecycle etc should be covered in well established patterns of naming and usage. See XP's System Metaphor concept.<br /><br />My main point in the talk was that documentation in and of itself is not a sign of quality. It may be the exact opposite. Automated build & deploy, automated tests, and great code readability would be much higher on my list of things to look for.<br /><br />- PeaceDave Kinghttps://www.blogger.com/profile/06124242031729205239noreply@blogger.comtag:blogger.com,1999:blog-3524127.post-27721419580480311202014-03-29T12:07:19.240-06:002014-03-29T12:07:19.240-06:00Thank you for speaking to us. And thank you for po...Thank you for speaking to us. And thank you for posting your notes here.<br /><br />You have inspired me in several ways. I now intend to focus my learning and effort to improve my ability to do the following:<br /> (a) Design that makes change easier (reduce cost of change).<br /> (b) Design for dominant usage (e.g. today -> mobile).<br /> (c) Design for ease of use (i.e. no user training required).<br />In addition, I have always tried to write readable/maintainable code that is correct. Correct in the sense of meeting the requirements. Then informing the "release decision makers" about any known deficiencies. However, I want to learn to do this much better.<br /><br />I intend to start by reading the books you suggested.<br /><br />I am very interested to hear more from you on these and related topics.<br /><br />On the issue of documentation. I agree 100% with you that<br /> (i) code is the primary design document,<br /> (ii) meta documents are expensive, hard to keep in sync, and therefore too frequently wrong (wrong implying source of cost rather than savings).<br /><br />I have always been taught and believed that documentation is a necessary evil. The idea of replacing it with something better is a very liberating thought. Did I understand you correctly, is this what you are saying? Can you recommend any references (in addition to Martin Fowler's Refactoring) that address this issue?<br /><br />For example, regarding "in-source" documentation and meta design documentation:<br /> (1) What documentation should be produced under what conditions?<br /> (2) Should programmers always look at the source code or are there ways to automatically extract the information they require? Required information such as usage details, inter-"module" relationships, life cycle issues (e.g. deprecation), etc.<br /> (3) What about meta information such as intended purpose, known deficiencies, potential improvements, etc? What information, if any, should programmers make available for other programmers (and probably themselves)?<br /><br />Thank you again for a very stimulating, thought-provoking, valuable presentation.Paul Mhttps://www.blogger.com/profile/05592016417545153719noreply@blogger.com