Often in my line of work, I need to create parameterized queries in code. All those overloaded constructors. Yuck. So, like a lazy guy would, I built a factory. I use it everywhere. In my personal projects and even at work when no one is looking. Here it is:

static SqlParameter CreateParameter(string name, SqlDbType type,
    ParameterDirection direction, int? size, byte? precision, object value)
{
    SqlParameter param = new SqlParameter(name, type);
    param.Direction = direction;
    if (size.HasValue) param.Size = size.Value;
    if (precision.HasValue) param.Precision = precision.Value;
    if (value != null) param.Value = value; else param.Value = DBNull.Value;
    return param;
}

And then when I'm building a command, I just do this:

cmd.Parameters.Add(DataAccess.CreateParameter("@RETURN_VALUE",
    SqlDbType.Int, ParameterDirection.ReturnValue, null, null, null));
cmd.Parameters.Add(DataAccess.CreateParameter("@ID",
    SqlDbType.Int, ParameterDirection.Input, null, null, id));
cmd.Parameters.Add(DataAccess.CreateParameter("@NAME",
    SqlDbType.VarChar, ParameterDirection.Input, 50, null, name));

Of course, it won't work for everything, but it makes quick work out of most of my parameter creation. Hooray for the factory.

I recently picked up Booch, Jacobsen and Rumbaugh's new book Object Oriented Analysis and Design with Applications. It's like the textbook I never had in the OO classes I never took. (Yeah, I'm just another self taught bozo who knows the difference between a five minute class exercise and a multiple month enterprise development project.)

Among others, I have especially enjoyed Chapter 6 called simply Process. Let me quote the opening paragraph and you'll know why.

"The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists. Amateurs often want to follow cook-book steps; professionals know that such approches to development usually lead to inept design products, born of a progression of lies, and behind which developers can shield themselves from accepting responsibility for earlier misguided decisions." pg.247

There's more and the book is a treasure trove of wisdom, but when I read this paragraph, it was nice to feel as if I had met the estimeed Booch, Jacobsen and Rumbaugh definition of professional software engineer.

I do remember looking for magic bullets when I first started teaching myself how to do software development. Fortunately through long trial and error and even greater opportunities to learn from true professionals, I gave up on looking for magic solutions long ago. Since then my life has been easier and busier and much more rewarding with regard to software development.

To their credit, the authors in Chapter 6 review the strengths and weaknesses of both agile and more traditional plan driven (sometimes called waterfall) process approaches. They begin their thesis in this chapter in addressing the traits of a successful project. Now having this is true magic. Here they are:

• "Existence of a strong architectural vision."
• "Application of a well managed iterative and incremental development lifecycle."

The killer qualifiers in those two statements are: "strong" and "well managed." Yikes! These are qualifications that are difficult to come by. When you do, grab them up and hold on to them for dear life. I think most of us can agree that "weak" and "poorly managed" will result in disaster every time.