tag:blogger.com,1999:blog-8546821102926874902007-12-28T20:01:09.337-08:00Code Renaissance-- Dave Herren --Blogger15125tag:blogger.com,1999:blog-854682110292687490.post-53988484062156228152007-12-24T11:20:00.000-08:002007-12-27T10:29:23.180-08:00Quality Software vs Healthy SoftwareI found a 2004 <a href="http://itc.conversationsnetwork.org/audio/download/itconversations-301.mp3">talk by Kent Beck(mp3)</a> on the Topic of Developer Testing on <a href="http://itc.conversationsnetwork.org/">itc.conversationsnetwork.org</a>. He talks about developer testing(unit testing) and how it leads to Healthy Software. I like the distinction he makes between Quality Software and Healthy Software. Quality Software is software that currently works as designed and lacks bugs. In contrast Healthy Software is software responds well to changes over time. It is possible to have Quality Software without developer testing but healthy software relies on developer testing. I've had to maintain a lot of Unhealthy software that's falling apart at the seams. Some of it was likely considered quality software in the first deployment, but lack of documentation and lack of unit testing doomed it to failure over time. If you need <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">encouragement</span> getting yourself or your team started in unit testing this is an excellent pep-talk.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-79743726093753892892007-12-21T16:39:00.000-08:002007-12-24T14:35:00.046-08:00Here comes another bubbleThis is a little off topic but I ran across the song "<a href="http://www.richterscales.com/assets/audio/rsrecordings/HereComesAnotherBubble.mp3">Here comes another bubble</a>" on a <a href="http://twit.tv/twit">TWIT podcast</a> a few days ago and I think it's hilarious. It's an I.T. parody by the <a href="http://www.richterscales.com/">Richter Scales</a> of the song "We didn't start the fire". I finally found a copy of the <a href="http://valleywag.com/tech/online-video/here-comes-another-takedown-332666.php?autoplay=true">music video on ValleyWag</a> (it apparently disappeared from YouTube on a Take-Down order). The video makes the song even funnier; I can't imagine anyone in I.T. not getting a chuckle out of this. If you haven't see it yet then you should. Enjoy.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-78660418033660282042007-12-19T17:13:00.000-08:002007-12-26T10:00:05.505-08:00Well-Factored CodeWhat precisely is well-factored code? The phrase grabbed my attention in a recent <a href="http://www.codinghorror.com/blog/archives/001022.html">post by Jeff Atwood</a>. It's a familiar concept; At a gut level this shouts at me: clean code! The self explanatory definition would be: code that has had an acceptable number of refactorings or, perhaps, code that has had all obvious refactorings performed on it. I googled the term to see how it is being used. From this search and, in particular, discussions in <a href="http://c2.com/cgi/wiki?WellFactoredCodeLeadsToBetterOptimizations">one wiki entry</a> I have inferred my own definition.<br /><br />Well-factored-code: code that is inherently readable, scalable, and maintainable but may be performance insensitive in certain contexts, platforms, and environments.<br /><br />To optimize the performance of well factored code certain defactorings, such as in-lining small methods, combining classes or rearranging data structures, may be required. In general though, the consensus is that well-factored code is easier is optimize because bottlenecks are easier to identify and the code is easier to change.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-84218830080055131602007-12-17T13:44:00.001-08:002007-12-24T14:42:24.036-08:00Don't think kitchen, think cookingI was listening to a <a href="http://ideaconference.org/2006/audio/21%20Robert%20Kalin%20-%20O,%20Advantageous%20Interfaces!.mp3">talk by Robert Kalin(mp3) </a> from the <a href="http://ideaconference.org/">2006 IDEA (Information: Design, Experience, Access) conference</a> in Seattle and I came across a saying that comes from architectural design "Don't think kitchen, think cooking". This is the type of thing that I love to latch onto. To restate this: avoid preconceptions by keeping your conceptual domain as large as is possible but no larger. The 'no-larger' part is very important and is driven home rather well by a long winded joke that my boss pointed me to "<a href="http://www.ridgenet.net/~do_while/toaster.htm">A toaster is not a breakfast food cooker</a>".<br /><br />I love to cook though I seldom get the chance. Mainly this is because wife says I make too much of a mess when I cook. I consider this point irrelevant; since I always clean up my 'mess' what difference does it make how big it is? In any case when I think kitchen my mind scans every kitchen I have ever cooked in and takes in the good points and throws out the bad and I have a pretty good idea of what a kitchen should look like. These are preconceptions. When I think cooking my mind jumps into creative analysis mode and I begin to consider the different points of cooking, what is convenient and inconvenient, and what needs to exist to allow me to cook easily. I once saw a picture in a magazine of an <a href="http://www.keidel.com/design/select/faucets-k-potfiller.htm">extendable faucet over a stove</a>. This is a great idea. When you needed to add water to a pot you simply extended the faucet rather than carrying the pot to the sink or getting a pitcher to carry water to the pot. This little detail is a major convenience that could only have developed by thinking cooking not kitchen.<br /><br />There's a shortage of good material on good design but I just found an excellent book on web usability and design called "<a class="lt-title" href="http://www.librarything.com/work/12322/book/24600800" target="_top">Don't Make Me Think</a>" by Steve Krug. I also found the transcript of an <a href="http://www.managementconsultingnews.com/interviews/krug_interview.php">interview</a> he gave on usability if you'd like to see what he's about.<br /><br />Another excellent book(not web/programming specific) on usability and general good design practices is "<a href="http://www.librarything.com/work/768/book/24075987">The Design of Everyday Things</a>" by <a href="http://www.librarything.com/author/normandonalda">Donald A. Norman</a>. The concepts he discusses carry over to programming.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-46993309297286621582007-12-17T08:58:00.001-08:002007-12-24T08:01:17.844-08:00Domain Specific LanguagesDSL are not mainstream and I have yet to form a cohesive opinion on them yet, but the concept interests me and I continue to look into it periodically. I recently found a <a href="http://podcast.thoughtworks.com/itmatters/01_ThoughtWorks_Podcast_1_Domain_Specific_Languages_part_1_of_2.mp3">podcast </a>with a good panel discussion of Domain Specific Languages on the <a href="http://www.thoughtworks.com/">thoughtworks</a> website.<br /><br />Here are two addition commentaries on the topic:<br />- <a href="http://codeaspects.com/blog/2">A DSL can change the way you think</a> (Joe Kutner )<br />- <a href="http://martinfowler.com/articles/languageWorkbench.html">Language Workbenches: The Killer-App for Domain Specific Languages?</a> (Martin Fowler)-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-37792247011566931592007-12-03T14:18:00.001-08:002007-12-24T08:02:34.691-08:00Cognitive errors in I.T.Cognitive errors are starting to be seriously evaluated in the medical profession where lives depend on proper analysis and effective diagnostics. I see a great need to apply these lessons in the I.T. arena as well. One common error know as <a href="http://blxit.wordpress.com/thinking-about-thinking-metacognition/">Anchoring</a> occurs when the answer that immediately comes to mind is the one that is focused on (often excluding all other possibilities). This often seems to be tied to <a href="http://en.wikipedia.org/wiki/Availability_heuristic">availability bias</a> where the likelihood of an answer being correct is judged by how easily it can be brought to mind.<br /><br />Common causes of Anchoring in I.T. include:<br /><br />1. Recent exposure to a solution e.g. "We'll use the umptyfart design pattern. I just read an article that said it is an excellent solution to this problem." Or "I heard Joe was having a similar problem the yesterday and he reformatted his hard drive and reinstalled everything and it worked fine. Let's try that."<br /><br />2. An unduly strong reliance on prior history e.g. "We're having a problem with the release of the XYZ application. It must be the config file again. "<br /><br />3. Confusing correlation with causation e.g. "We pushed out the ABC web application last night and now the LMNOP service is down; The new release must have broken it." Or "After (some candidate) was elected the economy got (better/worse); Clearly they caused the turn in the economy."<br /><br />While the above reasoning could increase the likelihood of an answer being correct it does not necessarily prove it to be true. Problems arise when other possibilities are not considered or evidence is not evenly evaluated. As a result of this the correct answer may not be found, critical time may be wasted, or unnecessary/harmful changes may be made. It's good to ask "If it's not this, what else could it be?" and briefly explore each possible cause mentally before deciding on a course of action. Often it can be useful if you can quickly eliminate several less likely but plausible causes before investigating a very time consuming but more likely one. Sometimes you luck out.<br /><br />Be wary of any possibility that you automatically eliminate as this can be rooted in a <a href="http://www.bauer.uh.edu/drude/4310.NOTES.part2.s05.doc">denial bias</a>. As an example, I recently I cleaned my wife's car just before we left the house on a date and found shortly after that I could not find my phone. It occurred to me (repeatedly) that my phone could be in the garbage bag, but I ignored this suspicion because I knew I would never throw my phone away. Thirty minutes later after prompting from my wife I was standing outside by the garbage dialing my cell phone with her cell phone; its characteristic chirp was clearly audible. In my defense I suspect that the phone fell from my shirt pocket into the bag when I bent to get garbage from the floor-board, but my wife insists that I actually threw it away.<br /><br />Two other common cognitive errors that are interrelated are Cherry-picking and Confirmation bias. <a href="http://en.wikipedia.org/wiki/Cherry_pick">Cherry-picking</a> is process of choosing only examples or data that support you position while <a href="http://skepdic.com/confirmbias.html">confirmation bias</a> is selective thinking where only items that confirm your conclusion are considered.<br /><br />An interesting book on cognitive errors in medicine is "<a href="http://www.librarything.com/work/2463700/book/22548809" target="_top">How Doctors Think</a>" by <a href="http://www.librarything.com/author/groopmanjerome" target="_top">Jerome Groopman</a>.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-7450021594338201982007-11-21T23:45:00.000-08:002007-12-24T08:04:49.276-08:00Question everythingQuestion everything.<br /><br />Question the answers you get, but more importantly question the questions you are asking. Learn, unlearn, relearn, repeat. Object oriented programming is tied to fast processing, as is the process of refactoring into well named concise procedures, but there was a time (and likely still is in some real-time programming environments) when huge procedures were common because every procedure call was a notable performance hit and object instantiation was considered a resouce hog. If all current constraints were thrown out the window what would the best programming model be? The ideas that I currently advocate are all at least 10 years old and moving mainstream.<br /><br />On my radar now are Aspect Oriented Programming and Domain Oriented Programming. I plan to delve into them some more to get a better understanding. I wonder if these will take root and what others am I missing.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-39698941461817166822007-11-21T06:09:00.000-08:002007-12-24T08:04:25.146-08:00Cherryh's Law<p>C. J. Cherryh is a popular science fiction author who has a law that she applies to writing.<br /><br /><a href="http://www.cherryh.com/www/advice.htm">Cherryh's Law</a>: No rule should be followed over a cliff.<br /><br />I think this has abundant applications in programming as well. Another (less catchy) way of stating this is that the rules must match your context and constraints. Some areas where this applies follow:<br /><br />1. Software methodology<br /><br />There are software methodology zealots out there. They demand absolute adherence to their doctrines, regardless of projects size or timelines and I have trouble buying into this. I don't believe in one size fits all. There are a lot of practices that I advocate but I allow them to be flexible based on context and constraints.<br /><br />I believe in design reviews, code reviews and unit testing but the level to which these are done will vary from project to project. Tight deadlines and few resources do not allow for strict adherence to these policies. It always comes down to the time-cost-quality triangle, given any two the third is decided for you. In some cases critical sections of code will receive focus where less critical ones will not. Aircraft flight systems programmers will have much different context and constraints than a business rapid application developer (like me) and in a context where lives are on the line I would expect 100% adherence to such policies and a CMM level 5 organization.<br /><br />2. Project management methodology<br /><br />There is a saying I once heard "A large company is not a big small company"; meaning that as your company grows you cannot continue managing things the same way because all the rules change as paradigms shift. In the corporate world this is a unidirectional concept but applying this to project management I would say that "A large project is not a big small project and a small project is not a little large project". Trying to use the same methodology on both will not work well. You must tailor your process to your context. You cannot manage rapid application development the same way you manage space shuttle software development. It always comes back to our old buddy ROI. There should not be 50 pages of forms, documentation and charts for 20 pages of code.<br /><br />4. General Policies </p><p>I received a bug on a website not long ago because it restricted length of an email address field to 35 characters and a client had a user who's email address was 40 characters long(I counted). This was because their naming convention was FirstName.LastName@Company-Something.com and the user’s first Name and Last name were both around 15 characters long. It's quite likely this user will have trouble in other places with this email address. Our site was changed to accept 50 characters, but perhaps we should have accepted 130 characters just incase someone has the following email address: </p><p><br />I.am.blindly.following.a.naming.convention.despite.the.fact.that.it.makes.the.email.address.absurdly.long@rediculous.IT.rules.com<br /></p>-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-23006035685524496272007-11-09T09:59:00.001-08:002007-12-24T08:06:30.378-08:00Dirty code? Clean it up! Refactor!Coding is a subjective science. I'm sure most of you have written code under pressure that just didn't feel quite right or perhaps had a design evolve under new requirement and realized the design was less than ideal. Some have spoken of code smells. I've always thought of code in terms of dirty and clean. When critiquing others I tend to refer to code and design as either 'feeling clean' or 'not feeling clean' as it is a little more politic.<br /><br />Dirty code in an application is like a baby with a dirty diaper:<br />1. you know its time for a change.<br />2. if you put it off too long you'll have a big mess on your hands.<br />3. eventually there'll be more changes needed.<br /><br />The answer to dirty code is refactoring, which is the process of changing code to improve readablility or structure without changing its functionality. Automated tools may be available to help with some refactoring depending on your development environment. A good introductory resource for best practices, including refactoring is <a href="http://www.amazon.com/exec/obidos/ASIN/0735619670/ref=nosim/librarythin08-20">Code Complete 2</a> by Steve McConnell. For an in-depth look at the topic I recommend <a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/ref=nosim/librarythin08-20">Refactoring</a> by Martin Fowler.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-58163965304837070802007-10-19T09:30:00.000-07:002007-12-24T08:07:18.668-08:00Interesting PhraseJust heard an interesting phrase: "Paving the cowpaths". It refers to creating programming automations for archaic processes. Instead redesign the buisiness with existing technology.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-79367888951862798472007-10-19T08:59:00.000-07:002007-12-24T08:18:18.324-08:00The RulesNovice programmers are learning the rules and challenge the rules they don’t like, whether the rules are good or bad.<br /><br />Mid level programmers know <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">a lot</span> of the rules, but are still learning. They follow the rules they like and resist the ones that they don't.<br /><br />Senior level programmers know the rules and have a dogmatic opinion of which rules are right and wrong.<br /><br />Programming Gurus are those who methodically question when and why to either break or follow the rules. They examine what contexts make the rules valid and look for changes in context. They question their preconceptions and are open to new opinions. They are the ones who eventually change the rules and the ones who make new rules.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-177422268627945942007-10-18T19:39:00.001-07:002007-12-24T08:20:01.408-08:00Aphoristic Code MusingsThe word-play that follows is my own. Hope you enjoy.<br /><br />Fixing bugs is easy; it’s figuring out whats causing them that’s hard.<br /><br />Hours saved in requirements will cost you days in rework.<br /><br />Hours saved in design will cost you weeks in maintenance.<br /><br />How fast your application is delivered will be quickly forgotten;<br />How reliable and maintainable it is will be often remembered.<br /><br />Unidentified stakeholders: faceless assassins who will use hidden requirements to drive a stake through the heart of your project.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-24778166560275163102007-10-07T19:03:00.000-07:002007-12-24T08:21:00.459-08:00Avoiding clipboard inheritanceClipboard inheritance is the practice of copying code from one location (class or method) to another in order to transfer functionality. It is highly likely to introduce bugs into your application for several reasons:<br /><ul><li>Any bugs in the copied code will be transfered to the new location.</li><li>Any fixes will need to be made everywhere the code was copied; it's easy to miss one.</li><li>Code specific to the old location can be missed when inserting and modifying the copied code.</li></ul><p>Instead follow the Once Only Rule: Any significant code should be in one and only one place in your code. </p><p>This will mean refactoring the code to extract the functionality. If the code is repeated within a class then it should be extracted to a new method that can be used throughout the class. If the functionality is used by multiple classes then the functionality should be extracted to a new class which can be used by the other classes (composition).</p>-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-57038630552471138372007-10-07T07:24:00.000-07:002007-12-24T08:22:51.702-08:00Clever KillsClever Kills. I heard this aphorism for the first time this week and it immediately struck a cord. I have found that one of the first casualties to clever or novel approaches is maintainability. There are two nails in this board that I often hammer on.<br /><br />The first is that complexity for complexity sake is evil. Complexity increases development time and reduces the clarity and maintainability of a project. It is important to evaluate the ROI (Return on Investment) on complexity in your code and design. An investment in complexity must yield returns in other areas (scalability, redundancy, configurability, deployability, etc) that are also a constraint of your application or environment.<br /><br />Notice that I said that what you get in return should be a constraint of your application or environment. Designs should be as simple as possible given your constraints; no simpler and no more complex. Even if you expect that at some point the application will have functionality added to it, a simple application can be easily refactored in the future to handle future demands. Requirements change and the further in the future the needs are, the less clearly they are seen. A small single form application for 3 users probably shouldn't use n-tier architecture (even though there are lots of benefits to n-tier architecture) unless such an approch is standard or otherwise required in your environment.<br /><br />This brings me to my second point; standard approaches are standard for a reason. They're typically clear and concise or, if they aren't, then at least they are well documented and widely discussed. Because of this -- and this is the best part about standard approaches -- anyone can maintain them. If you loose maintainability in a critical application (and when they're not working they're all critical, aren't they?) then it would take a huge trade off in another area to offset that loss.<br /><br />If there is a standard way that meets the requirements then use it. Standard approaches have stood the test of time. Odds are your clever solution will fail somewhere down the line due to things you couldn't (or just didn't) foresee.-- Dave Herren --tag:blogger.com,1999:blog-854682110292687490.post-91050707859114873832007-10-06T21:56:00.000-07:002007-11-21T05:40:12.578-08:00Code Renaissance<p>Welcome to code Renaissance. </p><p><a href="http://www.mirriamwebster.com/"><span class="blsp-spelling-error" id="SPELLING_ERROR_0">Mirriam</span>-Webster's</a> defines the renaissance as the "transitional movement in Europe between medieval and modern times" and "a movement or period of vigorous artistic and intellectual activity". Established fields like architectural engineer have already gone through their renaissance periods, which I define as times of great discovery and experimentation followed by standardization and reliability in the field. If a bridge fails, it is likely because well establish construction guidelines and design techniques were not followed. If a software development project fails, well, there are guidelines and design techniques that could be pointed to, but they are not yet widely agreed upon or used in the industry. In addition, I believe many are yet to be discovered as programming concepts continue to evolve. It is my goal to review important techniques and concepts, particularly those that I believe should be industry standards. </p>-- Dave Herren --