Prefactoring: Plan Globally, Develop Locally

Plan Globally, Develop Locally. Incremental implementations should fit into a global plan.

The main idea here is that as you go through your use cases and iterations, take few moments examine your objects to see if their structure makes sense, in broad terms, with the existing use cases as well as the planned ones.  You can't know everything you'll need to know before you start typing code but you can look at your planned implementation for the sprint to make sure you won't have to do a major refactoring later on.  If possible, try and keep changes as small as possible.  Changing the implementation of a class is less painful than restructuring an entire inheritance hierarchy. 

Prefactoring: Don't Repeat Yourself (DRY)

Don't Repeat Yourself (DRY). Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This is a really powerful idea to grasp and sometimes very hard to adhere to. Working on systems where you have to remember to change 4 different files just to make a single logical change is painful and error prone.  If you know you want to stay DRY, and who doesn't, then you start to see your solutions in a different light.  Sometimes you have to write a custom tool that churns through an XML file to generate the multiple pieces the system needs to support a new feature but at least you have a canonical definition of that feature.  One tool that might help to stay DRY is MPS.  You can create a custom language to describe the solution to a problem, such as generating Hibernate and JAXB aware Java classes from a single definition file.  Having to look multiple places to make sure a change gets through is going to cause a failure in the system at some point.

Prefactoring: Document Your Assumptions and Your Decisions

Document Your Assumptions and Your Decisions.  Keep a journal for retrospectives.

The human memory isn't very good -- at least mine isn't -- so it makes sense to keep a journal of the design decisions you've made as you've implemented the system.  The code will tell you what decision you made, but often times it won't tell you why you made that choice.  As the system evolves, those whys can become important as new decisions need to be made.  Did you assume that the system would be operating on a fast, reliable network?  Did you assume that nobody would ever want to manipulate that particular sub-system so no RESTful API was put in place?  Having a search capable repository of your decisions is useful in retrospectives as well as answering the age old question of "why did we do that again?"  I use a wiki to keep my notes, mainly because it is easy to use and is easily searched.

Prefactoring: Think About the Big Picture

Think About the Big Picture: Decisions within a system should be congruent with the big picture.  What does that mean? It is all about context, with the context being the system's architecture and business purpose.  The definition of architecture that I've come to love is "important things that are expensive to change".  For some systems, the message format could be considered part of the architecture because it spikes through all layers of the system.  For other systems the use of the Java EE stack would probably be part of the architecture because it would be a lot of work to shift to a POJO model.  If you can somehow get the entire team to share a vision of the architecture and make sure the important decisions are made based on the context of the architecture and its primary purpose, the project has a better chance of succeeding.

Prefactoring: Don't Reinvent the Wheel

Today, I'd like to begin summarizing some points from the book Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability by Ken Pugh.  The book is organized as a series of stories that highlight a particular guideline.  Each post will focus on a single guideline.  Today's is Don't Reinvent the Wheel: look for existing solutions to problems before creating new solutions.

As a developer, I'm as guilty as the next guy of Not Invented Here syndrome but I've come to appreciate the fact that if I'm going to get paid, I need to work on solving the problem and not creating a shiny new tool that I think will help me to solve the problem.  Sometimes I can grab an entire product from the open source community and solve the problem but often I have to integrate many pieces together in order to get things done.  For me, I tend to gravitate to the Spring portfolio of solutions.  I'm comfortable with the programming model and they tend to stay out of my way and let me focus on the problem at hand.  Most importantly, they free me up from having to write yet another custom configuration file parser or MVC web framework.  The faster I can create a solution the more I stay interested and the happy my boss is.