Scotty Factor

If you’re reading this, there is a good chance that you do some sort of project work within your job. My blog doesn’t attact a lot of people outside of IT and the typical IT guy is working on project X, Y or Z and sometimes all 3 at the same time. If this isn’t you, I’ll save you some time and you can stop reading now.

Ok, so you are working with your boss and he/she has assigned you a project. Maybe its mapped out with all of the details or if you are like me, you will typically get a broad project goal and its your job to come up with the milestones and timeline.

Its this last part that gets tricky. You don’t want to set the goal line so far out that seems completely unreasonable, but at the same time, you don’t want to underestimate and go on a death march to get the project done on time. That is a recipe for burn out!

So I’m going to let you in on a little secret that I use. This is especially helpful when dealing with sales people as they want to know what it will take and they don’t give a shit what else comes up that delays things. So the simple answer is what I call the Scotty factor.

Here’s an example of the Scotty factor in action…

James T. Kirk: How much refit time before we can take her out again?
Montgomery Scott: Eight weeks, Sir, [Kirk opens his mouth] but ye don’t have eight weeks, so I’ll do it for ye in two.
James T. Kirk: Mr.Scott. Have you always multiplied your repair estimates by a factor of four?
Montgomery Scott: Certainly, Sir. How else can I keep my reputation as a miracle worker?
James T. Kirk: [over the intercom] Your reputation is secure, Scotty.

Time Estimation

So am I saying multiple all your project timelines by 4? Yup, pretty much. I actually use a factor of 3, you might use something higher like 5. There is this philosophy that claims to use 5 and let management beat you down to something more realistic but nothing short of a factor of 2.

The main thing I want to stress here is…you probably suck at time estimation. I would say that 99% of us suck at it and that 1% are just really lucky at guessing. They’ll most likely be waaaaaay off the next time around.

Do yourself a favor and the next time you get a project and think, heck this will only take me a week to knock out, tell your boss 3! Even if you get it done in 1 or 2, you are a shining example of how efficient all employees should be.

Powershell Error checking

Being a programmer by trade, I get thrown into many projects that aren’t always my forte, but I can figure them out and get them working the way that I want.

I’ve been messing with powershell for a while now with VMware, but never really getting into big time scripting with it. Its mainly be something to use to accomplish some various tasks on mutliple hosts. Very little error checking in the scripts since I’m watching them was they run. If I want to put them into a scheduled task or automate them from a web page, more error checking is needed.

Recently, we starting messing around with automation of Exchange 2010 provisioning using Powershell. There are some great cmdlets to accomplish this, but I ran into a particular issue that really bothered me as a programmer and since I spent more than 5 minutes unsuccessfully googling the answer, I figured I’d write this post.

My issue was this, I was attempting to put some wrappers around certain cmdlets to get back whether or not they completed successfully. I hate to be the bearer of bad news, but shit doesn’t always run as you think it would.
I think I found a good way of handling the powershell scripts that do not return a true or false and were causing some false positives.

The issue occurred in the functions such as remove-mailcontact where I would have something along the lines of:

if(remove-mailcontact -identity $ID -Confirm:$false)
{
    "+OK Contact Removed"
}
else
{
    "-ERR Unable to remove contact."
}

This would alway return the -ERR statement.

So now I have expanded upon that and have the following:

Remove-Mailcontact -Identity $ID -Confirm:$false -DomainController $DC -ErrorVariable:err
if($err)
{
    "-ERR Unable to remove contact"
}
else
{
    "+OK Contact Removed"
}

This second method seems to be doing what I want and goes to the appropriate domain controller so I think I’m on the right track…we just need to update the various scripts now. For a little more information on the errorVariable adn other default switches you can pass a cmdlet, check out this blog post from the Microsoft PowerShell Blog.

HMC CreateFolder

Today I had the chance to get back to some code for CreateFolder which creates a public folder within our Exchange 2007 environment support by Microsoft’s Hosted Messaging and Collaboration frame work. I’ve been highly critical of Microsoft’s code before, and today has taken that to a new level.

Here is what I’m dealing with. First, let’s go to the documentation on TechNet:

Pretty clear that we have a few required parameters and a few optional ones to set some quotas. These optional parameters are what will soon drive me to uncontrollable rage.

Next, let’s look at the example directly from the web service. Here’s what it states we can pass:

POST /mpsws/ManagedEmail2007/Service.asmx HTTP/1.1
Host: prov01.bacon.lightedge.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://provisioning.microsoft.com/webservice/managedemail2007/CreateFolder"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <CreateFolder xmlns="http://provisioning.microsoft.com/webservice/managedemail2007">
      <CreateFolderRequest xmlns="http://provisioning.microsoft.com/managedemail2007">
        <Data>
          <organization>string</organization>
          <preferredDomainController>string</preferredDomainController>
          <name>string</name>
          <path>string</path>
          <server>string</server>
          <maxItemSize>string</maxItemSize>
          <postStorageQuota>string</postStorageQuota>
          <storageQuota>string</storageQuota>
        </Data>
      </CreateFolderRequest>
      <sendCredentials>boolean</sendCredentials>
    </CreateFolder>
  </soap:Body>
</soap:Envelope>

Again, everything looks great. postStorageQuota and storageQuota are both there and seem perfectly reasonable.

So let’s actually SEND that command to the web service. Here’s the error I get back:

The element 'CreateFolder_Request' in namespace 'http://provisioning.microsoft.com/exchange2007provider' has invalid child
element 'postStorageQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'. List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'.The element 'CreateFolder_Request' has invalid child element 'postStorageQuota' . List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' .

You get this is you change PostStorageQuota to prohibitPostQuota.

The element 'CreateFolder_Request' in namespace 'http://provisioning.microsoft.com/exchange2007provider' has invalid child element 'storageQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'. List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' in namespace 'http://provisioning.microsoft.com/exchange2007provider'.The element 'CreateFolder_Request' has invalid child element 'storageQuota' . List of possible elements expected: 'prohibitPostQuota, server, issueWarningQuota' .

In case you missed it, they changed the variable with in the back end server code, and failed to tell anyone that they made this change. Awesome!

This appeared only after we made the jump up to HMC 4.5 rollup 9. Before the PostStorageQuota and StorageQuota worked as expected. Needless to say, I’m less than impressed that they changed properties on me and failed to update the documentation OR the web service example. I guess figuring this out with trial by fire is the way that Microsoft expects you to learn. Thanks Microsoft!

When to kill a product

I’ve been out of college now for more than a decade and have worked for only a handful of companies. For a lot of people my generation, I’m probably seen as a dinosaur by not changing jobs every year once my stock options were vested.

But seeing as I’ve had a chance to move up in companies and produce multiple products, I have a different appreciation for product lifespan and code rot.

Product lifespan? Code Rot? What the hell is this loon talking about?

Software is much like owning a house, you have to maintain it. Issues (bugs) are found, new technology comes out that will make your product more stable and possibly cheaper to run. New advances in design and layout require a fresh coat of paint from time to time.

Eventually the software is a bit too much of a mess. Sometimes you have to gut a room or two. Sometimes, you just have to tear the whole damn thing down.

How do you know when its time?

For me, there isn’t one question that clearly lets you know when its time. For example: When was the last time you gave the product any love? When was the last time you added a feature or fixed a bug? When did you give it some marketing dollars? Has it been so long that you can no longer remember? Have you been distracted by other products? When was the last time you had a signup?

Its OK to admit that you have been ignoring a product. But now you have to ask yourself, how much is this costing me a month? How often is support getting calls on it? What are my hosting costs for keeping this around? Am I still making money? Would I have a company if this was my only product?

It quickly becomes clear on what you should do. We have a product at our company that hasn’t done as well as I would have liked. To be honest, it has a lot of issues. Most of which are out of our control. Due to licensing, its priced too high and competes with “free” alternatives even if they are less secure. It has maybe a couple hundred users on it and if it was our only product, we would have shut the doors a while ago. Its time for it to go.

Dealing with the breakup

So the hard stuff now has to happen. You have to either tell your customers to go away, or find an alternative that maybe you’re reselling, maybe not. There is a good chance that they’re not going to like what you are going to tell them. Break it to them easy, give them PLENTY of time to migrate away from your company if they choose. Bend over backwards to any request that they have for getting their data. After all, its THIER data! Helping users move their one service will hopefully keep those customers on the other services that they have with you.

In the end, this is best for the company. Even if you lose a customer or two, its best in the end. Even with the lost revenue, there is hopefully a huge reduction in expenses that can now be pushed to your money making products. And yes, even with repeating this to yourself, it will still suck. Good luck my friends.

Shipping Code

As a programmer, I have had the joy of seeing a lot of my code ship with various projects in my career. One thing that I have found is, no matter how much I have tested, no matter how solid I feel about the code, there is always that moment of anxiety right before it ships. Its a natural feeling as a programmer to have these. You constantly strive for perfection but in the back of your mind you know that you’re a human who makes mistakes.

Today is one of those days. We launch our revamped customer portal to our internal employees. Let’s hope all goes as planned.