tag:blogger.com,1999:blog-2247246257923129702.post7395663850930479067..comments2024-03-08T04:56:25.535+00:00Comments on Tim's blog: Avoiding duplication and increasing flexibility in software: what about version control?Tim Hunthttp://www.blogger.com/profile/01349724348368316287noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-2247246257923129702.post-26762389327521678422009-05-28T10:07:26.405+01:002009-05-28T10:07:26.405+01:00About giving configuration options an UI of their...About giving configuration options an UI of their own: yes, when thinking about the actual UI of an application, too many obscure options are harmful. Essentially they just show the developer failed to make a UI decision and tried to push the responsibility for the decision to the user when it should have been pushed to a User Experience (UX) designer.<br /><br />However, when you approach the point from configuration, no one is stopping you from using prograssive disclosure. As long as the way to access it does not distract the users who don't need it, a less prominent configuration screen may, depending on the context, increase flexibility. It just depends on the needs of the key personas involved whether or not this is appropriate.<br /><br />But the point about having constants right in the code to keep them close to where they are used was interesting. I bumped to this problem when I was still coding more actively and didn't see that way of thinking.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2247246257923129702.post-36695332815976566012009-04-08T15:45:00.000+01:002009-04-08T15:45:00.000+01:00A rather late reply. I agree that good software de...A rather late reply. I agree that good software design is evolved. However, I think that one of the ways it evolves is when you refactor the code to a known pattern. I do find patterns helpful when thinking about design, but they should be used in combination of a healthy dose of the YAGNI principle.Tim Hunthttps://www.blogger.com/profile/01349724348368316287noreply@blogger.comtag:blogger.com,1999:blog-2247246257923129702.post-20498038231564908612009-03-01T12:14:00.000+00:002009-03-01T12:14:00.000+00:00"The whole code is a configuration file"..."The whole code is a configuration file" - I like this idea Tim. I think it's especially true of Interpreted languages like PHP, that are (relatively) easy to read and understand.<BR/><BR/>Is the problem with design patterns that they give too much weight to design? Practitioners know that code is as much evolved as designed. Or maybe that design patterns and OO (although incredibly useful) are now falling behind the curve of where practitioners are at?<BR/><BR/>A coder may have an instinct of what is right for their particular project, given its particular language, particular architecture, stack, likely deployment, etc. This may be tacit knowledge for the developer i,e. they don't know that they know it.<BR/><BR/>They may sense good patterns that do not map onto existing theory.<BR/><BR/><BR/>>>"Millions of people around the world happily use and customise Moodle despite the lack of design patterns in the code. Should I be sad, or happy?) "<BR/>Be happy! A beautiful piece of code that is never sees the light of deployment is about as much use as a chocolate kettle :)<BR/>- EamonEamon Costellohttps://www.blogger.com/profile/03178388583209644842noreply@blogger.comtag:blogger.com,1999:blog-2247246257923129702.post-85862084170044885952009-02-20T01:17:00.000+00:002009-02-20T01:17:00.000+00:00Very interesting point, my (limited) experience wi...Very interesting point, my (limited) experience with computer scientists is that source control is rarely even considered. Though, what about open source software! Surely this is the real winning tool here!<BR/><BR/>But I think the contrast of drupal vs moodle helps the counter example here. With drupal, everything is a hook and this strength is used to build a flexible general purpose CMS which can be changed in more ways than can be imagined. Even on my own basic internal company site we use a set of 5/6 modules which often hook into the same points and do powerful things which end up integrating seamlessly, and cleanly.<BR/><BR/>Moodle lacks a massively flexible system of hooks, for this defect people generally tend to find it more easily 'hackable' to do as they wish. But moodles' scope of 'hacking' is limited and in many ways its enforced inflexibility is its strength. <BR/><BR/>I don't think that even a powerful DVCS like git would help you apply multiple custom modules which interact with each other at the same point - it'd be conflicts central.<BR/><BR/>Perhaps this is a gauge we should consider when designing where flexibility is required.Dan Poltawskihttps://www.blogger.com/profile/10220552827102091184noreply@blogger.com