Career Tip – How to not sound incompetent

A wise person once told me, management isn’t interested in what a problem is, they’re interested in a solution.  The wise person was also slightly intoxicated and we were at a bar, so I thought they were full of hullaballoo.. yet I never forgot that line, and it’s been pretty true as I progressed in my career.

In a project meeting recently, one of the members of the testing team, who was representing the testing group, was asked “what percentage complete are you?”.  After some stumbling and bumbling, they said “maybe about 20 percent?”… notice the question mark in that statement?  The project manager came back with “well, how many test cases have you completed?”, to which the testing engineer replied with “we have 53 cases and we’ve completed 0”.  Go head and check your math, twice if you need, but 0/53 is 0.. as in 0 percent.. as in 20 percent less than 20 percent.

The conversation went on where the project manager had to pull teeth to determine, why is it 0% complete?  Why did you state 20%?  What’s the hold up?  It wasn’t meant to be a confrontational meeting, but the testing engineer was defensive and giving up as little information as possible, and the project manager needed an accurate status to report to upper management.

In the end, the testing engineer had a problem, they didn’t have the proper tooling and training to do their testing, so they hit constant road blocks trying to get through their test cases.  You can’t blame her for that.. that’s an institutional issue and not a personal issue.. the personal issue is that she was absolutely un-willing to offer that as a problem.  That’s not a scape goat in any fashion, she was just un-willing to say “hey, I need some help here, I’m testing something I’m not familiar with”.  The meeting closed out with her being visibly upset, and other members of the project consoling her and offering her some assistance in understanding the system she was testing in.  All in all, it worked out OK, but the damage was already done, as she eventually stated “I just can’t wait for this <bleeping> project to be over with”.

Moral of the story here is simple, nothing’s perfect, and nothing ever goes according to plan, but be resilient and offer suggestions on how to move forward.  I’m astonished how often I talk to other software developers who encounter a system issue and throw their hands up in the air, stating “I had an error and didn’t know what to do.”  We live in the era of Google and Bing and Discussion Boards.  This is no longer a world that we can state “not my problem”, it’s a world of “accept ownership of the problem and offer a solution”, something so few seem willing to do nowadays.

My wise friend mentioned above was correct, management isn’t concerned with problems, they want solutions.  Have a problem, raise it to your manager, but also offer what could\should be done to help mitigate it.  What’s so wrong with saying “I was never trained in this?”, or “I don’t know what this means?”  At the end of the day, it’s not a good enough reason for a project to be behind schedule, and managers like employees who help make them look like rock stars.

Staged Deployment with Windows Azure Websites

Microsoft continues to deploy feature after feature with their Windows Azure service offering.  Recently I happened upon their staged deployment feature, and it’s so handy.. I thought  would write this post :)

So let’s start here.  Go ahead and bing some information on what takes place when you deploy a website to Azure.  I’m far from an expert on it, but Azure run’s through a number of processes to acquire a physical data host, generate the network mappings, deploy your application, and make it available.  I’ve noticed that when I repeatedly deploy an application to the same Azure Website, the build process goes fairly quickly.  My guess is that there are some comparison jobs going on, only deploying the necessary files.  Either way, the issue I’ve run into is when I generate a new version of code on my “build machine”, and attempt to deploy.  That’s where it takes several minutes.

All in all, it’s not terrible to wait that long, but it is limiting to when you promote to production if you know you can’t target a mid-day deployment because of this.  Staged deployments make this much more palatable. 

What is staged deployment?

Let’s start basic, what is staged deployment? With Azure Websites, you can take your Azure site, and “duplicate” it.  When you do this, 2 things happen.  One, you get a “-staged” version of your site (so if the regular site’s name was mywebsite.azurewebsites.net, a website is created called mywebsite-staged.azurewebsites.net).  Secondly, these two sites are now “linked”, meaning you can swap deployments between them.

How is this helpful?  With staged deployment, you can promote your production website, access the site to validate changes, and when the time comes, put it live.  When pushing new content to the staging site, your current site doesn’t take a hit… it’s not even aware that website files are being affected.  Heck, if needed, you can promote your new website build days in advance.

Once your files are pushed, and it’s time to put the new build live, you simply perform a “swap” action, and the new site is live in milliseconds.  Your users, or even endpoint monitoring, won’t detect a difference.

This seems really advanced, it must be difficult to setup.

It’s not.

Step 1 – Create a Staged website

Within the Azure web portal, go to your Azure Website.  Choose the “enabled staged publishing feature”

When prompted to create the staged version, choose Yes

Back within the Web Sites portion of your Azure Portal, expand your website node for the site you just affected, and you will see a “sub site”, with a (staged) suffix appended to the website name.

Now, go ahead and access the website settings for your new “staging” website.  It’s a normal website, and you can do everything with this website that you would normally do.  So now, grab your publish profile, and publish your website.

Step 2 – Push it live

At the end of the last step, I told you to grab your publish profile for your staged website.  Once you published to this site, you can browse the “-staging” version of your website.  If you feel your code is ready to go live, all you have to do is “swap” your deployments.

To do so, choose either your production website, or the staging version of it, and take a look at the “toolbox” at the bottom of your website:

In the toolbox, you should see the “Swap” command.  This will, in essence, flip the staging and regular version of your website.  When you choose “Swap”, you get a confirmation warning:

Confirm that you want to promote the site, and within a second, your site changes will be live.

“Oh Sh*t” Button

You promoted your website, and marketing calls you to tell you that some website features aren’t working as desired. You tell them they approved the website, and of course they don’t care.  With staged deployment, you can just “swap” again, pushing the previous release live.. all within seconds. 

Staged deployment is one of the many handy features of Windows Azure.