Developers Developing Development Database Data

Yes, I like consonance.

In this entry I would like to share my thoughts regarding the value I perceive in entering dynamic site data through a paired CMS within the vacuum of a development environment. While its fast and easy to simply switch a datasource to existing sample content, the avoidance of doing any content grunt work also has a price.

The first cost comes from the inevitable embarrassing and potentially gut wrenching scenario. Despite your best efforts the wrong settings get posted to a production server and you find that you’ve inadvertently populated the “Daddy’s Dancing Princesses” photo gallery with “Angry Engine Chicks.” While both of these feminine groups are charming, neither is receptive or understanding to your explanation of the data cross up.

The second cost is related to the detachment from the administrative user. Entering mass quantities of data sucks. While you might have built a functional administrative interface, the level of “suck” associated with data/content entry can only be gauged by spending time using the back end you develop. Getting intimate with the administrative interface will often shift a tool from the realm of “functional” to “easy to use” prior to external usability feedback. Having spent this time unofficially bonds you with the client administrator and helps avoid potentially hard to construe third party “improvement” requests.

The final reason I endorse populating development data is simply for enjoyment. Once the true development is done consider simple development content the frosting on the cake. Take a half hour to take your new site and administration out for a test drive. If you posses talents not of this world, v1 will be perfect. More likely you’ll find bugs that would have otherwise stayed hidden until further down the line.