Enterprise Etc Adventures and Insights of a .Net Developer

I'm in a situation, right now, where scope creep is a problem.  It's frustrating, without a doubt, but I started wondering why it was such a source of stress and made some observations.

I'm a person who likes things very ordered and I suspect that most good developers are successful at what they do because they, too, like things to be organized and ordered.  If your going to be using a waterfall type approach to manage the project, ordered means having to know, up front, what all tasks need to be completed and how long each will take.  Without this information, there's no way to know if the project is on track or not as it progresses.

Business people don't seem to work well, that way.  Typically, they'll get their hands on a nearly finished product and start finding exceptions to the rules that were first specified when the design was being made.  Bottom line, here, is that there will almost always be late-breaking requirements and modifications that will be specified.  Knowing this can get you half way to a point of being stress free.

The other half of the frustration stems from the fact that these late-breaking revelations are contrary to the method used to manage the project.  The whole process used to manage the project gets stood on its ear and the project goes into a kind of suspect status because our process is not equipped to handle this disruption of the project flow.  This causes stress on the development team and causes the project stake holders to get nervous.

If we accept as fact that requirements are going to change and that users are going to think of things they didn't realize during the requirements gathering stage of the project, and make that fact a part of the process we use to manage the project, these changes don't come as a surprise to anyone involved and the stress level drops considerably.  To the developer, the change is just another item on the back log of tasks and to the business side of the house it just means they're going to get what they REALLY need.

The key, here, is that you have to start the project out with an agile approach so that everyone's expectations are set from the get-go.  Trying to switch an existing project to an agile method somewhere in the middle is a sure recipe for crash-and-burn. 

     Try it for yourself, here.

If you're not following Scott Hanselman's blog, you should be.  His posts are always applicable and edgy.  If you know Scott, you know that he is a Type I diabetic and sometimes blogs about the struggles that come with having the disease.  He is currently promoting a walk to help raise money for diabetes research and you can find out more about it and how to help here. 

I am Type II diabetic and as such I urge you to check out the walk that Scott is backing and consider contributing to the effort. 

I recently had the chance to immerse myself in doing CLR development on Sql Server 2005.  The project I'm working on requires some complex pricing algorithms for varying combinations of products and doing the calculations in a "set-based" way just didn't feel right.

I needed to write several closely related stored procedures and did so in a single project.  When you create each procedure, Visual Studio creates a separate file for each procedure, but the files declare the class using the partial keyword which means that each procedure is actually just a static (shared) method on a single class.  As work progressed, I saw a number of opportunities to reuse some of the methods I had written across procedures.  This was easy enough since all the procs were actually in the same class...even private members we accessible from all the procedures. 

At some point, however, I realized that I needed to call one procedure from another.  This presented a problem, though.  I typically started all my procedure like this...

    . . . .

So, at the entry point of the first procedure, I opened a Context Connection and as soon as I called into the second proc, it tried to create another connection.  Since only one context connection is allowed per call, the attempt to open the second one failed.  I could, of course, call into the second procedure by creating a SqlCommand and executing it, but that feels dirty considering that both procs are actually in the same class.

So, after some thought, I determined a pattern that I intend to use from now on in such situations.  For all my CLR procs, the method that is the entry point for the procedure will be structured like this...

Now, I can call the code as a stored procedure (through up_DoWork), which is its primary purpose, and also call into the whole of the proc's functionality (DoWork) while passing in a context connection created in another proc.