Consulting 101: Credibility and Integrity

Let me preface this treatise with a message to those in my audience who actually know me in person. I’ve been doing what I do for almost 18 years. My blog posts are a compilation of observations stretching that whole time and back into my years in grade school. I do not refer to anyone in particular any of you and I may know. My blogs are mostly about me.
How many times can a restaurant you frequent get your order wrong before you stop spending your money there? How many times can a garage fail to fix your car before you take it somewhere else for service? As a consultant, contractor, or subject matter expert, how many mistakes is your customer willing to forgive? I don’t know either, so I always shoot for perfection.
In my practice, the struggle for perfection means I will not quickly offer my gut feeling on a solution to a problem. I want to research the situation and think it over for some time until I am comfortable taking a position. The discipline to be 99% sure about something before I share it helps me avoid mistakes. The more often I’m right the more my credibility builds. The buildup of credibility eventually leads to my customers’ increasing confidence in my work. And that’s great because, a lack of confidence in my expertise always manifests itself as more time wasted in explanations, healthy debate, and sometimes fruitless arguments about things I’m at least 99% sure of.
Relatively, I do not propose solutions that I cannot implement 100% myself. There is a theme of helplessness prevailing through some workplace environments; taking the shape of people who will not lift a finger to figure something out without being fully trained and having a stack of documentation. I’m going to put on my old fogey hat now and relate to you, my audience, how my first ASP web sites were written in notepad. My “simulator” was an actual Windows NT server with IIS and FrontPage extensions. In those days there wasn’t any documentation really because we were figuring it out as we went. I was handed a challenge that usually looked nothing like requirements and told to go figure it out. I did figure it out without training and it made a better professional out of me.
So when I say, “Let’s do it this way.” I mean I can do the whole thing this way myself if I have to. I’m 99% sure it will meet all the requirements on paper and the several that you haven’t thought of yet.
Now, I am human and I do make mistakes. Under the perfection mandate, I strive to find my mistakes and fix them before everyone notices. I once worked for a company where the products all had a call home feature. When there was an error the system would either dial in or FTP a message to a system in the home office that would create a ticket and kick off a workflow for resolution. I was so impressed by the fact that a customer could come in the office in the morning to find an email from tech support notifying them an error was detected and fixed remotely overnight and the customer suffered no outage as a result. I strive to conduct my business the same way by fixing an issue as soon as I determine it’s my responsibility and then explaining what happened and how I fixed it. That’s exercising integrity to build credibility. The value of building credibility is always greater than the perceived liability of admitting to bugs with integrity.
All that said, every action has its equal and opposite reaction. There will always be competitive forces… or persons who will work to build credibility through damaging yours. After all, it seems hard to build credibility by simply agreeing with someone else all the time even if the other person has a 99% success rate. The perception is that always agreeing with another makes one a follower or toady. Likewise, some resources are hiding the fact that they will not succeed with your proposal because it involves things they haven’t been trained on. Yes, the corporate business environment often mirrors school yard factions carving out various spheres of dominance. Woe unto the executive staff that has to always play teacher or referee. Truly, you have to pity decision makers who are constantly dealing with weak personalities who cannot tolerate others discovering they may not be perfect, so seek to advance solely through bringing down others.
The school yard provides the tactic for dealing with this. Get to teacher first! Luckily, if you’re catching, fixing, and admitting to your short comings before anyone notices, your competition shows up to tattle on you and looks rather foolish. Teacher says, “Yes I know. He told me and corrected the issue in such a seamless matter we never knew anything was wrong.”
Don’t misunderstand. It makes me sick that adults conduct themselves in this matter. It’s one of the reasons I sought the freedom of working for myself. Even now, when these situations arise, I suffer less than healthy rises in blood pressure. Why do we have to go through this schoolyard battle again after I’ve already built up all this credibility? The point is to revert back to the idea of not immediately going with gut reactions mentioned above. Don’t fall into the competitive traps. Diligently building credibility through accuracy and integrity should, in theory, pay off in the long run. Optionally, find a sub-contractor and throw them to the wolves.

I’m not a DBA, But I Play One on TV: Part 2 – CPU and RAM

In Part 1 I discussed SQL Server and Hard Disk configurations. Now let’s have a look at CPU and RAM. This topic is actually kind of easy. More is better… most of the time.


It’s my opinion that most development environments should have a minimum of 4, 2.5+ GHz Processors, If that’s one socket with two cores, or one socket with 4 cores or, or two sockets with 2 cores, doesn’t really make that much of a difference. For a low utilization production system you’ll need 8, 2.5+ GHz processors. Look, you can get this level of chip in a mid-high grade laptop. Now if you’re looking at a very high utilization system it’s time to think about 16 processors or 32 split up over 2 or more sockets. Once you get to the land of 32 processors advanced SQL Server configuration knowledge is required. In particular you will need to know how to tweak the MAXDOP (Maximum Degree of Parallelism) setting.

Here’s a great read for setting a query hint:

And here are instructions for a system wide setting:

What does this setting do? It controls the number of parallel processes SQL Server will use when servicing your queries. So why don’t we want SQL Server to maximize the number of parallel processes all the time? There is another engine involved in the process that is responsible for determining which processes can and cannot be done in parallel and the order of the parallel batches. In a very highly utilized SQL Server environment this engine can get bogged down. Think of it like air traffic control at a large airport… but there’s only one controller in the tower and it’s Thanksgiving the biggest air travel holiday in the US. Well the one air traffic controller has to assign the runway for every plane coming in and going out. Obviously, he/she becomes the bottleneck for the whole airport. If this individual only had one or two runways to work with, they wouldn’t be the bottleneck; the airport architecture is the bottleneck. I have seen 32 processor systems grind to a halt with MAXDOP set at 0 because the parallelism rule processing system was overwhelmed.

For more information on the parallel processing process:


RAM is always a “more is better” situation. Keep in mind that if you don’t set the size and location of the page file manually, the O/S is going to try and take 1.5 times of the RAM from the O/S hard drive. The more RAM on the system, the less often the O/S will have to utilize the much slower page file. For a development system 8GB will probably be fine, but now a days you can get a mid-high level Laptop with 16GB even 32GB is getting pretty cheap. For production 16GB is the minimum, but I’d really urge you to get 24GB. And like I said 32GB configurations are becoming very affordable.

Agile: The Consultant’s Savior

Thanks to Jeff Nall for contributing to this post.

How many times have you delivered to spec and hit your milestone only to get the “That’s not what I asked for.” feedback? Guess what, your customers don’t always know what they want much less what they really need. They might think they do, but if that were the case they would have been able to staff the project internally or with some new direct hires.

I once worked on a project where the company actually hired a consultant to translate corporate jargon into generic tech and software development terms. Apparently, they were struggling to find new hires or consultants with the skills they were looking for. Additionally, the resources they would gamble on were so lost trying to understand requirements, the development departments turned into revolving doors. The “Demystification Consultant” had a full time job translating specs and RFP’s so vendors could understand what to bid on. It might have been cheaper to adopt language learning methodologies and switch to a common communication device, illustrations.

In Agile that translates to frequent demonstrations of development progress. Rather than placing the entire project’s success on a nearly finalized demonstration of a product 2 weeks from delivery, Agile iterative development practices frequent illustrations of what the product will be so stake holders can approve or make changes with enough lead time to actually see the modifications implemented.

How does a consultant benefit from this process? Well like it or not, no matter what the contract says, an unhappy customer can remove a consultant and withhold payment if the customer believes they can argue in court that the contract was violated. Consultants are burdened with not just delivering what was promised on the agreed schedule, but also executing the contract in such a way that the customer wants to work with them again or act as a reference for other potential clients. Conducting frequent demonstrations: illustrates your responsiveness to your customers’ needs, reaffirms progress made on the deliverables  and keeps the lines of communication open for timely reactions to change. Agile is the best defense against “That’s not what I asked for” in the final days of your project.

The customer isn’t always right–they’re hiring you to answer the question for them. It’s your job to read between the lines of what the customer says they want and give them what they need. The point is the answers you get from someone who isn’t an expert in YOUR field can’t logically be the solution to the problem. You’re dealing with breadcrumbs, not road maps.