Our development team at TripConnect consists of a number of full time employees and also contractors that we bring in to supplement our efforts. Over time, we’ve been able to develop documentation, code examples, and other means to convey our development practices to developers that join our team. Read this before working on a data access object. Use this class as a model for developing your new Action class. Use this Eclipse snippet for importing this tile…We can’t afford to develop a full developers guide to our code base and the pieces that we do standardize tend to be reactive. When something that ‘smells bad’ during a code review, we educate the developer, and then (hopefully) we define the best(or better practice).

So my next few entries will cover some things that we discovered during the tenure of our last contract developer. He was a good developer; fast, smart, could read code very quickly, etc, but he had some coding tactics that we needed to address. Most of them were classic issues stemming from a lack of documentation on our part and his own inexperience in developing maintainable code. So for the first practice in this series, here’s a very (very) basic set of guidelines on building up an agile process for documenting best practices:

1) Start with some basic coding practices. (Look for this type of code in this folder… Here are some important utility classes. Use this class as a coding example).
2) Inform new developers on practices, code examples, etc.
3) Get the developer working quickly.
4) Spend the bulk of your time educating the developer on the key business and functional requirements.
5) Allow the developer to develop the initial solution with minimal technical information on developing the solution.
6) Require frequent check ins from the developer
7) Follow check-ins with some basic QA and followed by code reviews.
8) Feedback to the developer areas of the code that need changing.

This is pretty basic, so I will dive into more details in some of my upcoming entries.

Happy Holidays!