antipaucity

Starting this week, and continuing over the next several weeks, there will be several updates and expansions coming to my published Connexions Collection (original publishing comments), “Debugging and Supporting Software Systems“.

I would love to collect feedback and be able to incorporate any suggestions for improvement that you may have.

Please feel free to either email me via the “E-mail the collection author” link on the CNX site, or via comments hereon.

Back in 2009, Joel Spolsky wrote an article called The Duct Tape Programmer. Of everything he has written, I think this is the very pinnacle, and it is summed in one simple sentence in the middle: “Shipping is a feature.”

I’ve referenced this article twice before (in Feb and Sep of ’11).

Why is this so important in my mind?

I went back to school in 2003 to complete my bachelor’s degree in CIS. I had graduated in 2001 with an AAS in CIS from HVCC, and after finding nothing in 2 years of searching better than the job I had at Hertz, I decided a 4 year degree might help. I graduated from Elon University in Dec 2006 with my newly-minted BA in CIS. During my tenure at school I discovered that I didn’t really like the development end of Computer Science, and I instead preferred the analytical and integrational aspects of systems work – tying disparate tools together, improving internal workflow, etc – to help make individuals’ lives better and easier. In other words, I enjoyed finding ways to automate time-consuming and repetitive tasks to allow myself (and others) to focus on more interesting work – like figuring out how to automate more tasks to move up the chain.

I worked for a few places while I was at school (two different departments at the school itself, a pair of non-profits, and some freelance side work doing web site development). When I graduated, therefore, it was only natural that I ended-up with a pair of offers to work with automation tools – one from a company called Opsware, and one from a place called Network General. For a variety of reasons, I chose Opsware.

It wasn’t long after I started in Support for Opsware’s Server Automation [System] product that I became more and more sold on the product, and grew bored doing support – troubleshooting is fun, but with the paucity of good support tickets^*, large similarity of cases coming from customers, etc .. it just wasn’t “me”. Shortly after HP purchased Opsware I put in to move from Support to Professional Services – to, hopefully, get a chance to work with harder integrational problems than I would ever see helping people over the phone and via email.

Beginning March of 2008^{^} I moved from Support to ProServe, and did start to get a taste for the bigger systemic problems that could be solved with the Opsware HP BTO suite. While with HP, I had the opportunity to do the global delivery of HPSA 7.5 for HSBC – performing both installation and onsite mentoring/training in Chicago, NYC, London, and Hong Kong. I also did the replacement install of HPSA 7.0 (a non-upgrade-to release) for Home Depot in Atlanta to manage their 2200 stores. There were some other customers I worked with, too – but those were the two biggest.

One of the issues that has arisen with [nearly] every customer I have ever worked with it that they want what they’ve agreed to pay for in the Statement of Work (SOW) signed, sealed, and delivered by the end of the project – and if it’s not, they want good reasons to sign a CO (change order) to modify the SOW.

And it’s no surprise. When you cost someone nearly 7 cents per second to work for them, they want to see results!

One of the constraints, therefore, that needs to be constantly watched is scope creep – the insidious tendency for all projects to go beyond their intended purpose (violating law 47 of the 48 laws), exceed budget, and never deliver what is really needed.

My primary goal when I work with a customer is not, perhaps paradoxically, to “make them happy”. One thing I learned when working in support is that the customer is never right^!. You may have to pretend that they’re kinda right – but they’re always wrong. They do not know what they want. They do not know what they need. And they certainly do not know what is wrong if you ask them.

My primary goal when I work with a customer is to deliver what they have paid for. When possible, I will change course slightly (following proper CO processes) – but I want them to get what they have agreed to pay for. Ideally, especially now that I am in the architecture end of the world much more than ‘just’ delivery, I can work with them in the pre-sales process to get the SOW to something that approximates what they need. But I always aim to give them what they have paid for. Everything else is window dressing.

At the end of a project – whether as outside consultants, students, internal employees, at home, for work, etc – what needs to be seen is what was paid for.

Ship. Deliver.

Without those two, nothing gets done.

^{* _{I have grown so frustrated with support processes that I spent time a couple years ago writing a small eBook that includes a section on how to make good tickets. I’ve also written on ways to improve your support organization before.}
^ _{Just realized that means I’ve been doing ProServe or PS-like work for 5 years running, and have been with the automation suite for more than 6 now.}
! _{Before you become too concerned – I do realize there are a few good customers out there. But they are just that – few, and VERY far between.}}

Recently came across a seriously funky issue with one of HP’s products (don’t laugh – I know there’s loads of funkiness in HP tools).

HP Cloud Service Automation allows you to schedule requests in the future. It also allows you schedule end dates for subscriptions.

That’s neat.

Here’s the problem: if you delete a Service Offering (which allows something to be requested in the CSA catalog) while an active subscription is using it – any active subscriptions get delinked, and become unmanageable with the tool.

Now the dopey scheduler comes into play.

CSA’s scheduler works by putting all future items into a FIFO queue. What this ends up meaning is that if you have an item that fails (because, for example, you’re now past a scheduled end date, but the subscription is unlinked from an offering, so it can’t unprovision it), all other pending items fail, too. Even ones that should happen “immediately” – because “immediately” is still added to the scheduling queue… behind the erroring item(s). And since those items have errored, nothing can move forward.

This is stupid. (And yes – RFEs have already been filed over these problems in the product.)

Instead, have the scheduler put all items into a table – at the appointed time, iterate through the table and run everything you can – if it won’t run, flag it as an error, and move on.

This is how cron works. Why would you not use a commonly-accepted, reliable way of doing things? Oh yeah – you’re HP.

If you’re planning to write something for your product/software/tool – see if anyone else has done it before, and then try to mimic methods that work… please!

In my ongoing hunt to find worth-while tech books (most recently in the field of cloud computing), I’m here today to write about Cloud Computing in Easy Steps by David Crookes.

First to note – this book is NOT about how to deploy cloud computing. It is about how to use lots of free and inexpensive options if you are an individual consumer or small business.

That aside, this is a fantastic, easy-to-read and -understand reference for folks just starting to get their feet wet in the world of multidevice-accessible applications hosted “in the cloud”. Compared to Google Apps: The Missing Manual (review), thsi text does not try to go deep, and is far more recently-published (and, therefore, up-to-date) than Nancy Conner’s well-written, but 4+ year old, tome.

Crookes makes the concepts of detaching from purely client-side computing and applications less intimiadating than they sound at first blush to most novices (and, for that matter, to most “traditional” techies and “old school” business folks). He provides excellent starter material and handy tips, reminders, and gotchas throughout.

This book is not comprehensive – it is not intended to be: it is introductory and of a quick reference nature. It accomplishes precisely what it sets out to do:

The cloud is everywhere. Cloud computing looks set to revolutionize how we create, store and share data. Today’s big names, from Apple, Microsoft to Google, are embracing it to such a degree that the world is moving from a centralized computing platform to one that can be mobile, scalable and always available.

Whether you’re a small business looking to reduce storage and application costs and make collaboration easier, or an individual who wants to use more cloud based services but isn’t too sure where to start, Cloud Computing in Easy Steps is the book for you. Each of the key concepts is covered in plain English, and many of the most popular cloud services are explained. (the back cover^*)

Whether or not you should buy this book for your own shelf is up to you – I found that it’s a good one to have borrowed from my library and learn a couple nifty things I didn’t yet know about some of my favorite services. It is most certainly a good text to read.

I learned about the call command in Windows recently.

Some context – was trying to run a command via HPSA at a customer, but kept getting an error that the program was not a recognized internal or external command.

Very frustrating.

Then one of the guys I worked with suggested adding a “call” to the front of my script. That worked like a champ. Here’s why.

When the HPSA Agent on a Managed Server receives a script to run from the Core, it runs it in a headless terminal session. This means that while environment variables (eg %ProgramFiles%) expand properly, if the first part of the command is NOT a built-in from cmd.exe, it won’t execute. Unlike *nix which is designed to run most things headless, Windows never was (and isn’t still as of Win2k8R2).

The built-in command ‘call‘ forks the next command to a full session (albeit still headless), and enables cmd.exe to run it properly.

Now you know.

The first comment I have about Barrie Sosinsky’s book, Cloud Computing Bible is that it’s the first one I’ve read that doesn’t appear to have any sucky parts.

This is a plus.

Hybrid Cloud for Dummies was pretty much a waste of time.

Deploying OpenStack was even worse.

Sosinsky’s work, though, is not only less temporally-constrained, but actually provides a huge amount of useful information in a nice, tight package.

Pages 27-28, for example, demonstrate a list he calls, “”The laws of cloudonomics” (drawn from Gigaom). In summary:

1. Utility services cost less even though they cost more
2. On-demand trumps forecasting
3. The peak of the sum is never greater than the sum of the peaks
4. Aggregate demand is smoother than individual
5. Average unit costs are reduced by distributing fixed costs over more units of output
6. Superiority in numbers is the most important factor in the result of a combat (Clausewitz)
7. Space-time is a continuum (Einstein/Minkowski)
8. Dispersion is the inverse square of latency
9. Don’t put all your eggs in one basket
10. An object at rest tends to stay at rest (Newton)

While the book does use individual exemplars (often open-source), Sosinsky took great pains to make as exhaustive a list as could be at the time of publishing – and indicates every time a list is about to be encountered that there are more options that were missed.

A few items in the book are dated (like Google Apps: The Missing Manual was). However, the vast majority of the content is as useful today as it was in 2011 when the book was published. This is an impressive accomplishment for a technical book. Especially for one written in the approximately-nascent world of cloud computing.

This is one of the few tech books I would recommend to anyone interested in the topics of cloud computing. I haven’t bought a copy … yet (my library has a pretty good system). But I want it.

Knowledge capture, retention, and dissemination has been an interest of mine for a long time. I have written about various aspects of it before.

The most vital commodity any organization has is the knowledge of its members – it does not matter if it is a historical society, company, church, or school: the organizational knowledge base is vital to ongoing health of the organization.

I love the picture of the “Tree of Wisdom“: at the ground there is a meadow of data, from this data information roots are gathered, the roots grow into knowledge branches, and at the end is the application of that knowledge in wisdom leaves.

Data is easy to come by.

Information similarly so.

Knowledge, taking information and transforming it into a more-usable form, is important.

When to apply that knowledge – aka using wisdom – is the topic for another post.

Capturing Knowledge

There are a host of available tools for capturing knowledge – text files, brown bags, PowerPoint, SharePoint, blogs, Plone, wikis, etc. The “best” on to use is the one you use.

Culture

Getting team members to contribute to organizational knowledge pools can be difficult – unless it is an organizational priority .. a part of the organization’s culture.

Incorporating this culture switch (if it’s not already innate to the organization) needs to be done not merely as a top-down directive, but encouraged via bottom-up interest.

Retaining (Managing) Knowledge

Now that you’ve captured (or started capturing) the organization’s data, managing it becomes the next task of import.

For example, should the KB article written 5 years be updated, replaced, or left alone?

Who is responsible for managing all of the information that has been collected? Will it be self-managed and -directed, will there be a curation team, will it be a combination?

Who determines the process for taking “internal” knowledge and “promoting” it to “outside” knowledge?

How are these roles going to be managed as the team changes memberships through people leaving, entering, and shifting in the organization?

For extremely small organizations, formal curation may be unnecessary. Perhaps since everyone knows everyone else, or the knowledge domain is so small, everyone’s individual contributions will remain fairly static and the “promotion” path will merely be proofreading (eg a historical society’s archives – the archives may be extensive, but the material doesn’t ‘change’ all that much (excepting being added-to, of course)).

For very big organizations (like the MSDN documentation available on microsoft.com), many layers of curation are likely going to be needed – proofreading, formatting, verifying, etc.

Finding the right balance of self-direction and organizational management can be tricky.

Disseminating Knowledge – Getting The Word Out

All of the captured knowledge in the world is useless if you can’t find it – and knowing where to look is vital. A close second to knowing where to look is how to find it.

Where is it?

There needs to be a solid document, landing page, directory, table of contents, etc so that new members (or folks who forget) can find the tribal knowledge that exists ion the organization.

As a part of the new-hire\introduction\etc process\period, be sure to tell new members where information can be found, and who to talk to about certain major topics.

Finding it once you know where to look

“Search is a hard problem.” Google’s own Udi Manber said that. Anna Paterson at Stanford wrote, “Writing Your Own Search Engine Is Hard”.

Search in general may be hard, but many tools handle at least basic (and some fuzzy) searching well – OSQA, WordPress, Plone, Drupal, and many others. If, in addition to categorization, a tag taxonomy is employed, quickly finding content relevant to the searcher’s wants\needs.

“A tag is a keyword or label that categorizes your question with other, similar questions. Using the right tags makes it easier for others to find and answer your question.” {SO description}

Knowledge contributors should be the primary agents of tagging. However, consumers should be able to suggest additional tags. Administrators\curators should be able (under unusual, but well-defined, circumstances) to remove tags.

The human factor

For any given topic / knowledge region in the organization’s realm, there need to be established “experts” and “mentors” who will help guide new individuals through the fog to locate the buoys to be able to navigate themselves into a clearer understanding of the new world they have been made a part of.

Apprenticing upcoming experts into the organization is the single most vital aspect of the knowledge capture process – if it is not disseminated, it doesn’t matter if it is captured.

After several years of pushing all of my personal email into Gmail, I’ve decided that relying [almost] exclusively on one provider is just not the best idea ever.

Google is great. But, as with any cloud service, exclusively relying on just one provider is not the best.

Going forward, I am going to be relying on my own server (which I have been indirectly for several years), as well as Yahoo. And Microsoft Live for Domains (which is freely available the way Google Apps used to be).

I love cloud computing – right now, it’s a major component of my job function. But it’s not a panacea. Everything has its place, cloud computing included.

So, I am not saying “goodbye” to Google. I’m just saying “hello” to others

Many years ago, I started programming C++ with a friend of the family and member of my home church. We dove in with Borland C++ for Dummies by Michael Hyman and Stephen Prata’s C++ Primer Plus (Waite Group). Prata’s book was fantastic – if you were at the advanced high school / collegiate level. While precocious in some areas, I was only 13: and it was too advanced by far in most of its topics.

Enter the “for Dummies” book. Hyman’s accessible, funny, and progressive pedagogical style was fantastic – and not just for me. Jeff also benefited because, while he “knew” C, he was really a Fortran programmer by trade. So he wrote Fortran in C. And then as we learned C++ together, we wrote Fortran in C++.

That aside, I became a fan of the “for Dummies” series because they took [generally] difficult and/or broad topics and condensed them into a format that I could grok rapidly, and could then branch from quickly – kind of an advanced “Cliff’s Notes” approach. In a style not generally as condescending as the “Complete Idiot’s Guide” and “for Mere Mortals” series, the “for Dummies” books were great intros to a variety of topics for me.

I picked up Hybrid Cloud for Dimmues by Judith Hurwitz, Marcia Kaufman, Dr Fern Halper, and Daniel Kirsch expecting to see something I could recommend to non-techies and/or stodgy types who are interested in quickly and summarily grokking cloud technologies.

As has been the case with several other books recently, I’m glad I didn’t pay for the book – the time it took me to skim the material and pick out any nuggets I either was not familiar with, or interested to see a potentially different spin on was about 30 minutes.

Pro Tip: always check to see if your library has a book before committing to purchase from Amazon, Barnes & Noble, Books-A-Million, etc

Clue #1 (which I would have gotten at my library had I spent a smidge longer with the book before checking out): all four authors are partners with Hurwitz & Associates.

Clue #2: no mention of HP’s competition to the IBM SmartCloud product line (which, ftr, has been around longer than IBM’s) – Cloud Service Automation and hpcloud.com^*.

Clue #3: barely any depth in any of the chapters … more like a “Cliff’s Notes” book than any other from the “for Dummies” series I’ve run across (which is fairly evident even in the TOC with how close subsections are to one another).

Synopsis

If you truly know absolutely nothing about cloud computing – private, public, hybrid, etc – and the associated *aaS acronyms – PaaS, IaaS, SaaS, etc – then you can pick up slightly more than is in the most recent issue of the in-flight magazine on your favorite airline in the course of a couple hours of skim-reading this book.

If you know anything about cloud – don’t bother. While I am happy introductory materials exist, if you are going to totally neglect some vendors’ offerings, you need to NOT promote other vendors over them – without some form of disclosure indicating why!

If you are wanting to give your CEO something they can skim and perhaps gain some mini insights into cloud computing because they want to keep up with all their peers who are “going into the cloud” … well, he should be able to finish it during his lunch break – without losing any chewing time.

For everybody else … spend 20 minutes on Google or Wikipedia – it’s cheaper, and far more likely to be useful down the road.

^{*_{I work for an HP partner, and have been immersed in HP Enterprise Automation products since before HP purchased Opsware in mid 2007}}

Google Apps: The Missing Manual by Nancy Conner was a great book. In 2008.

Today? Not nearly so much. So much has changed in the Google landscape in the last few years (or even months) that, sadly, much of the content is now quaint, or just out-and-out wrong.

It’s too bad – because the book is very well written. It’s accessible to a variety of audiences, and one I would love to recommend to anyone interested in, or currently using, Google products.

However, with the passing of Gears and the free edition of Apps, this text is not nearly so helpful anymore – at least to me.

And with the constant stream of updates to the online apps coming from Google, it’s not going to be much better than a primer for anyone else.

Maybe Ms Conner will do an update – I hope so, because I bet it’d be a great resource [again]. But if Google continues to change direction and policy as they have so far, it would likely again be out-of-date too quickly.

Printed books about technology are fantastic – when they cover something static like Microsoft Office 2010 or compiler design or data structures and algorithms. For web sites and apps? Not so much.