Jeremy D. Miller -- The Shade Tree Developer

May 2008 - Posts

• My friend needs some help on an article

  I would never do this, but a "friend" of mine has procrastinated entirely too long and let a deadline for an article sneak up on him.  Here's a couple ideas that my friend has for his next article.  The article has to be on design fundamentals from a relatively ideology agnostic standpoint (not overtly pro-Agile or TDD in other words).  His first article in the series on the Open/Closed Principle will appear next month.  Please think about which topics would benefit your team members too, Mr. "I know the basics cold" Alpha Geek. "Design Vectors" / "It's the Little Things" / "A title that doesn't stink" -- Why do you care about Encapsulation, Coupling, and Cohesion.   Then follow up with some heuristics to push your design towards these qualities.  Tell, Don't Ask, Law of Demeter, Don't Repeat Yourself, and a bit on some Code Smells.  My friend wants to sneak in an example of using a lambda expression to remove duplication.  Yes, Mr. Alpha Geek, you've read the Pragmatic Programmer front ways, backwards, and sideways, but this is for a more general audience. Creational Patterns -- Builder, Factory, Abstract Factory.  Then talk about using an IoC tool as a generic way to implement these patterns.  The importance of separating functionality from the grunge work of assembling object graphs.  My friend isn't that excited about this one. Object Stereotypes -- An introduction to the idea of object stereotypes from Responsibility Driven Design.  Apply these stereotypes to some bigger patterns like MVC/MVP.  It's an under appreciated topic. Inversion of Control as a Pattern -- Forget the IoC/DI tooling.  Let's talk about how, why, and when this pattern is useful. Patterns for Persistence and Data Access -- Lots of stuff from Fowler's PEAA book.  Unit of Work, Database Mapper, Active Record, Row & Table Gateway. Anything sound good to you?  My "friend" would appreciate some opinions here. Posted May 07 2008, 01:03 AM by Jeremy D. Miller with 37 comment(s)

• Would you do it differently today?

  A year and a half ago I wrote a post called My Gameplan for Starting a New Project from Scratch that just detailed my thoughts on starting up a new project.  I was asked via email last week if I had any changes to that post.  Yes, absolutely: Follow it Through! Don't jump into the work too early without a good story backlog definition, an understanding of the goals of the system, and some inkling of the expectations of the client (which are undoubtedly going to turn out to be ridiculously unrealistic). All processes, even XP and Scrum, have some sort of fuzzy project conception phase.  The activities that you perform in that phase are crucial to the success of the project by preparing the field, but easy to neglect because there isn't much pressure upfront and the feedback loop that says "you're wrong!" hasn't started yet.  On the other hand, I think you need to work with a sense of purpose early in the project to get through that initial phase and get started.  In My Gameplan post I talked about the importance of getting momentum early on in the project.  That's largely based on my experiences in a large organization that let the early phases drag on way too long.  After doing three projects and starting a fourth since that post, I'd still err a little bit on the side of starting the coding in earnest too early rather than too late.  I did have some issues with coding outrunning the build, test, and deployment infrastructure.  Take care of that stuff as early as possible.  Especially early on the project, if you see chances to add some automation to reduce friction, do it right then.  Investments early on pay off more in the lifecycle of a project.      Posted May 01 2008, 11:04 AM by Jeremy D. Miller with 4 comment(s) Filed under: Starting a new Project