Jeff's Blog

One of the most useful things for a developer to have in their bag of tricks is a bevy of canned sample code. Having a simple project of Domain objects, as Simple DataAccess project that pulls static data, or reads from an included data source, a Business logic layer, and a simple UI (the more platforms the better) to render the Domain objects can save hours when you want to do a quick proof of concept on a new technology. Say you want to see what this new LINQ stuff is all about, grab your DataAccess, Domain and UI layers, and experiment away. With a few minutes of setup you can be writing the code you want to explore rather than building up the infrastructure around it.

Here are a few rules I try follow to both build and maintain these canned pieces:

1. Keep it simple – For IDs use integers. The idea is not for these layers to perfectly mimic production code rather to be extremely easy to extend and manipulate. Things like data type integrity are not essential for the most part, what type you store and retrieve something like a Zip Code as is not as important as the how.
2. Have unit tests for each project in each project, again this is about simplicity, not production code. Having the tests in the same project helps insure they are kept up to date as you extend and modify the component.
3. Try to be generic in your architecture. You may think the MVC/MVP is the new hipster chocolate, but you're not always going to get to use it, so try to keep each individual layer as generic as possible. Remember that it's not to0 difficult to inject intermediary layers, to mimic a particular architecture when you need it.
4. Always work with copies of your stock projects. I like to keep a Zip each component and then completely re-extract it when I want to use it for a proof of concept. This helps keep the project free of case specific code.
5. About every 3-6 months, review the projects against what's new in the world of .Net development, for instance with this project I'm converting my Domain object to use the new field-less properties from .Net 3.5.
6. Try to be diverse. Having just the typical Customer/Orders code stack can limit your creativity when exploring new technologies, as well as leave blind spots in you view. Try to have more complex relationships and hierarchies. Companies, with Locations, that may be regional HQ's that have satellite locations or Colleges, with departments, classes, professors, assistants, and students in a very intermingled set of relationships. Having complex objects can really help work the kinks out of a potential UI, or DataAccess approach.
7. Share and borrow. These types of utility components are great things to put out as free software. And using Google/CodePlex to help build your library is a good way to get started.
8. Experiment often. The point of these class libraries is not only to make functional proof of concepts easier, it's to make all code exploration easier. There are so many new ideas introduced into the world of software development every day, that it's just not possible to be fluent in all of them, but just spending 20 minutes dabbling with something new can end up saving you hours of work down the road.

Essentially the idea is to have a rich toolbag. Form days long ago I remember having my stock example code of the ADODB.Create… snippets that I could copy and paste into every new project that I spun up. It was both that I didn't like the idea of having to remember the exact syntax for such routine tasks (this was in the days before intellisense/j), and that in the end for better or worse, Speed of Development is a metric that many employers use to evaluate the quality of their developers. Showing solid stable results in short order goes a long way towards building the trust required to do real developmental work in software.