Thursday 13 October 2011

ArmchairCIO Mourns Dennis Ritchie

Dennis Ritchie, one of the most influential people in the development of modern computing, passed away on October 8, 2011. Dennis designed the C programming language, and developed much of the Unix operating system. Its not my intention to go into great detail on the evolution of either of those. It suffices to say that C was the spark for languages like C++, Java, C#, and Objective-C - upon which most of the world's software is built. Without Unix, we would not have SunOS, Linux, or MacOS X - heck, even the iPhone runs a stripped down Mach Unix kernel.

I felt compelled to write a tribute blog, because a lot of attention has been focused on Steve Jobs death on October 5, 2011. Without the work of the demure Dennis Ritchie, Jobs wouldn't have much to sell. I saw no mention of Ritchie's passing in the major news media. Most of it is still homage-de-Jobs and the recent Blackberry outage. I think that is truly a shame because Dennis Ritchie's contributions and what they enabled are truly astounding.

In the summer of 1986, I was in my second year of university, taking summer courses to correct a "lack of discipline" I experienced in my first year. The University of Calgary computer science department allowed me to have an account on their DEC mainframes, even though I wasn't taking any courses that really required it, because I had asked the administrators for access in order to learn C (in order to learn how to fully utilize the Unix operating system.) I'm grateful for the patience those administrators showed me, because I had a knack for getting into trouble (with computers.) Dave Mason and Keith Andrews, if you are out there, thanks.

I bought the K&R C book by Ritchie and Kernigan (on Dave Mason's advice), and I was amazed how quickly I picked up the language; literally two weeks. Previously I had learned the procedural languages Basic, Pascal, Modula-2, and COBOL, and one thing about C stood out: it was concise. In very little text, requiring very little typing, you could build sleek programs. In some sense, that lack of verbosity was very enabling - especially at a time when auto-completion and code-generation didn't exist because most terminals/computers didn't have the horsepower.

I spent the next 20 years programming in C, or C derivatives like C++ and Java. This language was really a keystone in the development of everything digital. From your digital devices, their drivers, operating systems, to desktop computers, or other electronic devices; chances are a C compiler of some sort was used to turn that source code into machine instructions enabling them.

So thank you Dennis Ritchie, thank you for providing us the tools that continue to allow us to explore and solution the digital future.

Friday 7 October 2011

Human Capital

My opinion on certification has changed. I am taking a journey towards a Certified Information Systems Auditor (CISA) designation and have joined Information Systems Audit and Control Association (ISACA.) I also plan to take at least one environment and sustainability certification in 2012. Professional development and self improvement are excellent goals. The personal networking opportunities are also incredible. I am not 100% convinced of the value of the various hurdles placed to maintain any certification, for example the thousands of dollars and a month of time on continuing education via conferences and what not. In my opinion, experience, aptitude and self-directed learning are still trumps in that game.

As I study up for the CISA exam using the CISA Study Guide by David Cannon (amongst other resource), I'm noting a lot of scrutiny in the realm of IT outsourcing that further validates some of my beliefs on the topic. I've seen some interesting notes and experiences, including:
  • Outsourcing is done for a variety of reasons
    • scope of work is unknown (we can't afford to do it ourselves)
    • staff isn't competent or experienced (we don't know how to do it)
    • upper management thinks it is a good idea (not a core competency)
    • we're CMM level 5 and anyone could do our jobs (we've got it totally figured out)

  • If a company and its outsource have not both performed an independent audit and/or shared those results before the contract is signed, there is only "hope and prayer" that the company's service requirements will be met. (p.150)

  • Outsourcing must be based on facts and evidence. (p.337)

  • If you're not CMM level 5, don't bother outsourcing.

  • Many outsourcing initiatives are done for the wrong reasons and possibly half end up in "in-source return" situations (p.136-138)

I also continue re-reading Death March by Edward Yourdon. Everyone in IT should read this book as its almost as instructional as Scott Adam's Dilbert. (It is amazing how in over ten years since this book was written, nothing much has changed.) I've gone over the section on process dynamics a few times, and years ago I shrugged at the Abdel-Hamid software process model, but now it is meshing with my thoughts on effective staffing and building corporate value.

I've read that human capital brings three things to the table that can be abstracted; training, expertise, and awareness. Training is what you can be educated on, and in IT, it would be the technical aspects of a job (like a programming language.) Expertise is your exposure to business knowledge and how to apply your training (like building Health and Safety applications.) Awareness is knowing how your organization works and who to talk to overcome obstacles. The intuition that comes with that is incredibly valuable, as you may learn when to ask questions and learn from the experience of others, as opposed to re-inventing the wheel.

Outsourcing can be okay at the technical aspects, but expertise can be problematic (as stated in previous blogs) because to keep the cost down, an outsource tends to (attract and) hire less experienced workers that likely don't have direct domain (business) experience. They are even worse at awareness, because the outsource is not part of the company's business culture.

I think many in the business would agree that a good senior resource can accomplish work in half the time it would take a junior resource. The senior resource has probably solved the problem before, or has parallel knowledge. The senior resources should be the norm against which all work is measured. These are the folks that have been with a company long enough to know how to get things done within the organization's culture. There are also experts, or gurus, that ascending above the average senior resource and tend to move mountains with their thoughts.

Consider the following diagram, where the Y axis is cost per resource, and the X axis is time in months. The work is constant (as the functionality of an end product would be the same.) Let's assume the junior resource cost $50/hr (2/3 of the senior resource) and takes twice as long to do something as a senior resource at $100/hr. Let's also assume that the guru is being measured at $150/hr, and he can move about nine times faster than the junior resource.



It seems obvious to me that assigning senior staff to a key project is both cost and time effective. And the really important thing is these staff represent in-house resources. Outsources don't have the gurus because they can't afford or retain them, and they have fewer senior resources because that domain knowledge is missing and they're insulated from a client company's culture.

The other part of the junior resource problem, as I gleaned from the Yourdon notes, is the buffer time it takes to get junior or senior resources engaged on work. Some might call this the learning curve, but it is more than just a technical aspect as you learn the tech, the domain, and the environment. There are other buffers as well (that may be bureaucratic or resource scheduling in nature.)

Here is my extension of the resource process model, including the concept of buffers, and adding some feedback. For posterity, let's call it the Wieser model of Human Capital.


At the start of process, new hires come into the system. You can measure their rate of entry. Once in, they will be assigned work, and you can also measure the "Rookie Buffer", that is, how long it takes them to achieve baseline (senior) performance. This feeds the assimilation rate. Sooner or later the junior resources evolve into senior resources. An important thing implied by the diagram is training. You can infer the effectiveness of training by the same means (because it should decrease the time it takes to do the work, and also decrease the number of iterations and/or errors.)

Once the resources have been assimilated (and that means they have the technical skill, the business experience, and cultural awareness) you can again measure and define baseline performance and know the pulse. The next big thing is the exit rate, that is, assuming the junior resources become senior resources, watch what happens to them. There are some interesting metrics here, because it can guide your adjustments to the entry rate.

LostA resource may get redirected, that is, take a different career path within the organization.
FiredA resource may get let go with cause.
QuitA resource may leave for some reason (that is important to figure out. Did they get a better offer? Was there something negative about the working environment? Threats lurk in high exit rates.)
RetiredResources retire (but tracking early retirement is an important indicator for culture.)
DiedAccidents happen, but work place accidents or related incidents need to be watched very carefully.
DiscontinuedThe resource, for whatever reason, was no longer required.


The big thing missing is exit rates at points of interest. For example, if you spend a lot of time and money training resources that balk during the training or shortly thereafter, that is a very alarming cultural indicator. Some put this into the retention rate and measure it over milestones like on-boarding completed, five, and ten year anniversary.

Now, if you look back at outsourcing, either as a company that is in transition to outsourcing and is having attrition issues, or as an outsource where you may have a culling of senior herd to keep profit margins high, you will see the model is front-end loaded. The true value and potential of developing the human capital will not get realized.