Commitment is a funny word these days. Most people do not understand what it means to be truely commited to something (or someone). Commitment can in some cases be interchanged with “loyalty” from time to time, but in the case of today’s discussion, commitment means “commiting to an act or trust” (m-w.com).
In consulting your commitment is important. Your commitment to your job, your client, and even yourself are all extremely important. Without commitment, a client would not know if you can be trusted to complete the job. Future clients will look at your commitment on other jobs to determine if you are worth both their time and their money. So to remain commited is important.
But being commited to a project is not everything. There is a commitment to a certain level of work. Since you are in effect, selling yourself (or your firm) you need to consider that when you turn in work. The higher quality work that you turn into your client, the better it looks for all those involved. Your client will appreciate the high quality of work, and this can lead to future engagements.
Commitment is something that can be difficult to physically show. Since everyone works differently, some people can still turn in a higher quality work but look like they are slacking. Some people can deliver the highest quality 8 hours a day, while others need a break every now and then. This does not mean that someone who looks like they are not working is not delivering high quality work. So you have to consider this when you’re working. However, perceptions are powerful things. If you look like you aren’t working then most people will assume you are not. So perceptions are something to keep in check when you want to display proper commitment.
How can you as a consultant display commitment to your project(s)? First and foremost, you want to turn in your deliverables on time or ahead of schedule. You also want to turn in quality work. Your work is a reflection of you. If you are not turning in your highest quality work then you are doing a diservice to everyone (including yourself). Turning in work ahead of schedule is a great way to demonstrate commitment, but turning in an inferior product in hopes of beating the schedule will only cause you more work in the long run and if you do it enough it will give your client a bad perception of you (and/or your firm). Most clients would rather you deliver a higher quality product a little behind schedule then the would an inferior one ahead of schedule.
Another thing you can do is to occasionally check in with your client boss. Ask them how they feel you are doing or if there is something you could do better. Be careful not to ask too often, as this could give them the impression that you are only worried about “looking” good rather than actually being good. Checking in every couple of weeks (or between deliverables) is a good way to keep a gauge on how you’re doing.
You can combine the occasional check-in with random checks on your work. Show the client what you have and where you’re going. Give them a chace to know what’s going on as well as make important decisions about the direction of your deliverable. This ensures that the client is aware of where you are within the schedule and can even make changes to that schedule if he feels that he can get something better if you work a little longer on it. Most Aglie development methodologies do something like this, so if you are in an evironment that is utilizing agile you will probably already be doing this.
Another thing to consider when discussing commitment is the fact that sometimes the client will ask you, the consultant, how long something is going to take. When this happens you have a couple of options. The first is to defer an answer until you have a better understanding of the project or deliverable. Don’t delay too long though, as it can look like you are stalling. The other option is based on your past experience, if you know you can do the work in a set amout of time then let them know how long it will take. If something comes up that is going to delay your orginal estimate make sure you tell the client the moment you are made aware of the impact. Unless your client is just completely unreasonable, this shouldn’t cause a problem. You can not predict every single thing that could happen in the course of a project and you should not be expected to be able to. But you are expected to communicate effectively.
As you work on a project make sure you are giving that client your highest commitment. Some days can be hard but always try to get something accomplished. Your goal is to deliver the highest quality work to your client(s) and to do so you must be commited to them and your work.
Michael Koby 
The Case for Stored Procedures
I’ve seen a lot of talk recently that is against the use of stored procedures when designing and developing database & data driven applications. There seems to be a real desire to purpetuate the idea that use of stored procedures is a bad idea. While in some instances this is almost certainly the case, it is not a hard and fast rule.
The Idea of “Best Practices”
Almost nothing in development is a hard and fast rule. And “best practices” are not always best. Everything is dependent on the exact situation you are in. Sometimes it can be your client who sets the ground rules. And while most clients are reasonable, sometimes they come from a time when things were in fact, done a certain way and they don’t really have a desire to deviate. Some clients will hear you out and make a shift to a different method if proven that the new method will work better. Sometimes, the situation just calls for things to be done a certain way.
Stored procedures to make database calls can fit into all of the categories mentioned above. Stored procedures are not fun to write or deal with. If you have to write one, then you must understand what is and is not the best way to to things. You must understand things like database performance, T-SQL “best practices”, and even the inner-workings of your DBMS (Database Management System). If you are not the one writing the stored procedure, you are at the mercy of your database administrator. If your company/client has a good DBA, then you have nothing to worry about. However, if they have someone who does not know what they are doing, stored procedures can be a hinderence.
Where Stored Procedures Fit
When it comes to deciding when to use stored procedures, there are some things to consider. FIrst and foremost is what language are you using to code your application. I can speak from experience when I say, if you are not using C/C++, using stored procedures is going to make your life far easier than not using them. This is true for most low level languages.
Another place that you might want to use a stored procedure is on the reporting side of things. When it comes to report, the way that report looks will change drastically over the course of a few days. Which means you have to shift your SQL code around when things change. Sometimes storing the database logic in a stored procedure can be best. This truely serparates the data logic from the application logic.
Where Stored Procedures Don’t Work
If you’re using something like .Net or Java to develop your application, there is little need for stored procedures (but there can be cases where you will use them). The reason for this is because .Net and Java make it very easy to separate business logic from interface logic. Also, there are tools that can help you separate things further if you need to.
Another place where stored procedures don’t work, is when you have a database administrator who does not care too much about database performance and thus does not write stored procedures with performance in mind. If you have a database administrator like this, don’t bother, try to get your company/client to allow you to put the code in your application code base. You can do this by proving that your code returns results faster than the provided stored procedure.
Something to Chew On
Keep in mind that there is rarely one correct way to do things. Using stored procedures has it’s place just as not using them has their place. Nothing is set in stone and in some cases using a stored procedure makes perfect sense. The Alt.NET movement is all about find the best way to do things and nothing should be thrown out just because it’s not a “practice” that you find acceptable.