So last year a bunch of us PowerShell smarty-pants donated a crap-ton of our own time and energy into putting together the PowerShell Deep Dive book.  The book is full of amazing content, and you should buy a copy for that reason alone.  I mean, just the chapter on automating software builds is worth the entire price of the book and I’m sure the author is also ruggedly handsome.

Look, in all seriousness, the proceeds from this book go to Save the Children, an organization dedicated to helping children around the world have the basic necessities for healthy and productive lives.  So, please consider purchasing a copy of this book, for any of the following reasons:

• to read it
• to gift it to someone else
• you need a giveaway for a user group or event
• you have or are considering a secret crush on one of the book authors or editors
• you have OCD and your bookshelf is unevenly stacked on one side
• your desk tends to defy gravity and you need to weigh it down
• you need to appear smarter or more attractive than you actually are
• you have about $35 of filthy germ-ridden cash of which you really need to rid yourself
• you use PowerShell, you suck at it, and you’re not ok with that

Once you purchase a copy, you can continue to help this book raise money for Save the Children in several ways.  First, tell others to buy their own copy.  Second, whenever you’re in your favorite brick & mortar bookstore, just ask them if they have it.  Most larger book stores keep track of these inquiries, so the more you ask, the more copies they’ll stock, and the more money will go to charity.

Unless of course, you want the children of the world to starve, which … you know ……

… by not buying a copy ……..

… it seems like you do…………….

I’m pleased to report that I’ve been renewed as a PowerShell MVP for another year!

I spent the bulk of 2013 focused on making open-source software – much of it orbiting PowerShell and integration with various technologies like transactional file systems and scriptcs.  I was nervous about losing the award by focusing less on teaching and speaking, but thankfully the team saw value in what I’ve been up to.

Looking ahead, I don’t plan on changing my focus much.  I have plenty of projects in the pipeline (pun intended) that I want to get to a release point in the coming months, and yes most of them still orbit PowerShell.  No reveals here, but perhaps a few hints – do you work with large SSIS package deployments?  Do you like the idea of SeeShell but not so much the cost?  Oh, or maybe you find yourself wishing PowerShell could just learn things by looking at data?

Sound interesting?  Then perhaps you should keep a close eye on my little blog this year.

March marks the passing of a personal milestone: four years of working for myself.  So this is the point where you make jokes about my boss being a jerk or the fact that no one else would hire me.  S’ok, I don’t mind.  It’s why I’m here.

This past year was crazy.  By design really.  I didn’t end up doing all the things I planned to do, but hey, “the best laid plans …” and so forth.  Besides, being able to pivot as I see fit is one of the first reasons I’m independent, and I am pretty happy with the way things have turned out. 

Here are some of the highlights from the past year:

• I’ve pushed six new highly-targeted open source projects.  And there are more coming in the next year, spanning automation and discovery frameworks for business intelligence to some nifty shell-aware data visualization tools.
• I’ve released several major revisions to StudioShell, including support for Visual Studio 2013, a version specifically designed for the Nuget package manager console, along with an example of how to use it in your own Nuget packages.  So, you know, go on and use it.
• I’ve published two new Pluralsight courses (log4net and PowerShell Gotchas!) which, if I do say so myself, are very well done.  In addition I have another course in the works which should be out in the next month or two on publishing custom performance counters in your applications. And it too is very well done :)
• I’ve learned more about scaling application data layers and SQL server than I really ever cared to.  Still, it’s been an interesting and view-shifting journey, which I always enjoy.
• I’ve expanded my speaking horizons with soft-skills, architecture, devops, and of course software development talks.  Moreover, I hope the coming year will find me speaking to new, larger, and wider audiences as well – for instance I’ll be presenting three sessions at the upcoming PowerShell Summit in Redmond next month.
• I’ve started fiction writing again.  I don’t do it very well or very often, but I’m learning to enjoy doing it poorly and infrequently.
• I opened up about a dark part of my life; not for commentary, not for attention, but out of gratitude to those who support me and concern for those looking for their own support.
• I’ve learned a new instrument – the ukulele.  I love it – it is impossible to be angry or stressed while playing a uke.  And it seems to please the right people and annoy the crap out of the others.  So you know, win-win.
• I’ve crocheted four baby blankets, one massive ugly afghan, and countless hats and scarves.  Currently working on baby blanket number five; seriously, y’all need to stop making them babies.

Of course it’s not all rainbows and unicorns.  I know there are things I need shore up and put real focus on.  Businessish things.  And I’m working on it.  Seriously, shut up about it.

At this point I would make some statements about what I plan to do in the coming year.  Outside of what I’ve already mentioned, I’m not doing that this time.  Instead, let’s just say I’m heading where I need to go at the pace I need to travel. 

Which is, after all the point of all this responsibility and effort right?

I’ve spent the last week slammed with unplanned work for a client.  No lie, it sucked.  In a nutshell, the system was asked to perform at a new scale it was simply not ready to handle.  Having read The Phoenix Project recently, I was especially cognizant of the loss of time caused by us flailing around reactively. 

As happy as I am to say that the system is now coping with the extra load, getting there was hell.  And on inspection the problem was obvious once you saw it at the proper scale.  That is, the problem didn’t become a problem until the load increased.

And that’s how performance problems tend to manifest.  Things are fine at one scale, but broken at another.  It reminds me of this magnet my mom used to keep on the refrigerator that read:

It’s not the mountain that wears you out, it’s the grain of sand in your shoe.

Which is so true: you don’t even notice that grain of sand until you’ve walked miles, cut up the bottom of your foot, and bloodied your shoe.  Then it’s an obvious thing – it’s painful and you can’t ignore it.

Thinking in Scales

Like anything, achieving performance is a balance.  You want the best possible performance for the least cost and effort.

The way I tend to think about scales – whether we’re talking about time, people, requests, whatever – is by powers of growth.  For instance, imagine planning a party for a group of people, and consider the challenges as the guest list grows to:

• 1 person
• 10 people
• 100 people
• 1000 people
• 10000 people
• 100000 people
• … and so forth

That is, planning a party for 200 people isn’t that much different than planning for 100, but planning for 1000 is WAY harder than planning for 100.

For time scales, I find it helpful to think in the following units:

• nanoseconds
• milliseconds
• seconds
• minutes
• hours
• days
• weeks
• months
• years
• decades
• centuries
• millennia
• geologic time

For example, during planning meetings you’ll frequently hear me ask “are we talking hours, days, weeks, or months?”

Now in the realm of scaling software, here is the money question:

At what scale is the system be expected to operate?

An application that needs to support 100 operations every second can be designed very differently than an application that needs to support 1000 operations every second.  The logic applies to bugs too: small performance issues that can be ignored at a small scale become debilitating as you scale up your effort. 

Just like that grain of sand in your shoe – it probably won’t be an issue while you’re fetching your mail, but you might want to address it before you head up Grandfather Mountain.