http://www.lazyinitialization.com Creating better software just in time. Fri, 12 Sep 2008 02:32:05 +0000 http://backend.userland.com/rss092 en Don't Repeat Yourself.  It's a powerful principle for eliminating duplication in code to facilitate easier change.  It should not stop there though.  If fully embraced, DRY can help you improve your system, your team, and even your organization.  Automating testing, deployment, and other processes can free up more time to ... http://www.lazyinitialization.com/2008/09/11/please-dont-make-me-say-this-twice/ When creating new software it is important to give simple meaningful names to the features and concepts that we create.  This allows us to communicate effectively with other team members and, more importantly, the users.  It can sometimes be difficult to give names to all of our concepts.  I believe ... http://www.lazyinitialization.com/2008/09/02/new-rule-if-you-cant-name-it-you-dont-need-it/ I'm looking forward to the day when I don't have to do agile software development anymore.  In fact I believe that we should all be working hard to bring the agile movement to an end.  Allow me to explain. I'll start by taking a look at the original Manifesto for Agile ... http://www.lazyinitialization.com/2008/08/25/working-to-end-agile/ Your code may be a bad influence on you.  When you set out to tackle a specific task driven by a certain customer need the code can quickly lead you astray.  Sometimes it tempts you with juicy refactorings that look relevant to your task but end up being long distractions ... http://www.lazyinitialization.com/2008/08/19/i-dont-want-you-hanging-around-with-that-code-anymore/ It has happened to just about all of us. Your customer has a requirement X. You recognize that you can satisfy X as well as Y and Z and innumerable other needs that you are certain will be the the customer will have in the future easily if ... http://www.lazyinitialization.com/2008/08/14/your-framework-probably-wont/ The use of TDD along with mock objects while designing for testability can help us to write extremely high quality code.  In fact I have learned that practicing these techniques regularly can help move 100% coverage away from a nearly impossible (and questionably valuable) goal and much closer to a ... http://www.lazyinitialization.com/2008/08/08/creating-better-mock-tests-with-hamcrest-custom-matchers/ The field of software development has no shortage of metaphors.  There's engineering, construction, and manufacturing to name a few.  Since no metaphor does a perfect job of capturing the essence of what making software is all about, I always enjoy exploring new ones to see what else they can teach ... http://www.lazyinitialization.com/2008/08/06/cooking-up-some-software/ I have read a great many things questioning the value of the measurement of test coverage.  I believe that there is a common misconception about test coverage and what our coverage numbers can tell us about our code. The common criticisms are that while the coverage report can tell us how ... http://www.lazyinitialization.com/2008/07/31/cover-me/ Patrick Kua has a post about a topic I've thought about a lot recently: the power of a true team vs. a loosely organized group of people working together.  I believe he is spot on about there being significant benefits to building a tightly integrated team.  He even offers some ... http://www.lazyinitialization.com/2008/07/29/spotting-a-team/ Sometime is the last year I had a conversation with a colleague who was not yet convinced about the value of agile development processes.  This particular individual was a good engineer who had made it his practice to write top quality code when provided with a detailed specification.  He just ... http://www.lazyinitialization.com/2008/07/27/building-bridges/