Last night I was finishing up an article on “Persistence Patterns,” and I was using a VB6/COM project I did years ago as a negative example (and not because it was VB6). On that project, every time we needed to access data or write data back to the database, we would do the whole rigamarole of “get connection string, open connection, build command object, execute sql, close database connection” and, oh yeah, try to remember to throw some error handling in there somewhere. We wrote a stupid amount of repetitive code. I bet 75% of my time on that project was devoted to data access. On the next project (VB6 as well), my friend and I came up with a crude “Xml to Sproc” mapper that isolated the ADO manipulation to a very small area of the code. I still wrote a lot of PL/SQL, but I realized a major savings in time spent fooling around with ADO objects.
My point is this, I had no mentorship from more senior devs on the first project, and I bet that that’s still the situation for many of us today. Centralizing that kind of data access code is considered to be a standard best practice on any halfway experienced team, yet nobody told me that on my first project. I was the “technical lead,” but I was as green as you can possibly be. How much easier would that project have been if I had just had someone more senior involved in the project to guide me towards a better design?
We constantly gnash our teeth over how our industry just isn’t “mature.” We propose certifications and guilds and brown bags and whatnot. Maybe all we really need to do to start is just help each other out with bare bone basics first. Like teaching developers to eliminate repetitive code in your data access layer like I did and this guy did in an MSDN article. Or, and I know I’m shooting from the hip here, we find a way to get junior devs directly exposed to somebody willing and capable of mentoring.
