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.

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.

Lost	A resource may get redirected, that is, take a different career path within the organization.
Fired	A resource may get let go with cause.
Quit	A 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.)
Retired	Resources retire (but tracking early retirement is an important indicator for culture.)
Died	Accidents happen, but work place accidents or related incidents need to be watched very carefully.
Discontinued	The 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.

There are no silver bullets.

A friend recently forwarded me a blog about a Gartner survey that had interesting statements about the relationship of CIOs to other executives, specifically the CFO. Some bold statements were made. CIOs are more about solutioning and tech du jour as opposed to financial control. Many large companies demand solid financial and risk controls, so where IT doesn't contribute to the bottom line, it should absolutely be reined in.

I believe there is an obvious answer to why there is a trend to transfer power back to the finance folks. Some CIOs suck at execution. They don't even know that they suck; they believe they are doing a good job (the Dunning Kruger effect.) There is an old Turkish saying: The Fish Rots from the Head.

Why is it that some CIOs suck at execution? There are many factors I'm sure, but it really needs a discussion on what execution means in a business context. Execution is the ability to deliver in a timely fashion. Get 'er done b'ys. The term execution excellence has been bounced around. It adds more dynamics about the leadership and motivation skills at the head.

Getting back to why some CIOs cannot execute, perhaps some of these breaking points apply:

• there is no clear strategy beyond "support the business" possibly coupled with a lack of understanding of the business and inability to set priorities


• does not engage staff in the trenches (that is common for strict hierarchical organizations or disconnects like outsourcing)


• introverted and lack people skills


• weak leadership


• cannot effectively communicate


• cannot coordinate across business domains


• does not play well with others (king of the hill)


• gather upper IT management around them that isolate them from reality


• do not trust their staff

If a CIO cannot deliver a good product and service, then they deserve to be marginalized under financial scrutiny.

So let's rephrase the negatives as positives. A CIO can nail execution if they:

• have a clear strategy


• understand the business needs and requirements


• have the ability to effectively triage


• are in tune with the issues coming from the front line staff


• exude confidence and are personable


• can rally all staff behind a vision or initiative


• are good communicators


• can coordinate across business domains


• are team players and foster team play


• support openness and transparency


• delegate effectively

I'd recommend the latter for any executive job description.  The only thing missing for a CIO is IS/IT experience.  If the CIO is all that (and a bag of chips), then they're worthy of being on equal executive footing.

Top Ten Outsourcing Lies

Top ten lists are very popular, so after a recent meeting where I was hearing a few positives of IT outsourcing, I had a strange sense of Deja Vu.  Now the word lie is a bit strong because it implies a conscious, wilful deception.  I do not believe all folks that sing the praises of outsourcing suffer from some affliction.  I'd like to think the quote attributed to Napoleon Bonaparte is a better fit:  Do not ascribe to malice what can be easily explained by incompetence.  That said, this top ten list can also be used as a check list to ensure you have the right outsource and agreement in place.  It doesn't matter if it is a service, product, or project.  The proof is in the pudding as they say, and if you cannot evidence any of these items, you are not setting yourself up for success.

#10         An outsource improves business continuity.

It is naive to believe, unless it is in the contract, that an outsource has an Emergency Resource Plan or Disaster Recovery Plan that is as strong as your business requires.  Think of it this way, if you pass the treasure to someone else for safe keeping, are you sure you'll get it back?  Will it be there when you need it? Many outsource companies have in their contracts a limit on liability to the cost of their service and not the value of the treasure.

#9           An outsource has comparable or better security.

Is the outsource's perimeter security and information security policy as strong as yours?  This should absolutely be in the contract, but like point #10, the further away from you the break-point is, the harder it is for you to do something corrective quickly.  There is also the irony that by opening a conduit to the outsource you are actually adding another break-point (that is out of your control.)

#8           An outsource has better quality.

Quality is very subjective unless you try to quantify it through solid metrics.  At the end of the day service satisfaction, cost and timeliness are bottom line indicators.  Defining Quality can be a job in itself.

#7           An outsource is faster.

There may be a few reasons why folks think an outsource might be faster, but the reality is usually Mythical Man Month:  The more people there are involved in a process, the greater the logistics overhead, the more opportunity for iteration and clarification, and the longer it takes.

#6           Outsources execute better.

Does your outsource measure its execution?  Do they share that data?  Do they compare to peers?  Do they believe in management frameworks or systems to guide all aspects of their operation?  Do they have a Continuous Improvement program?  Are their resources experienced and happy?  An embeded resource has a face and a certain level of trust.  Many outsources are black boxes.

#5           Outsources are cheaper.

You can't add the logistical overhead without driving down the other labour costs, especially for near-sources.  The first TCO reduction comes from releasing your trench staff.  If you presume these workers were paid competitively and were skilled to start, and were also loaded up with appropriate work, how can it possibly be cheaper by adding more expensive resources (like project managers, case managers, client managers) and cheaper resources (that equates to less skilled or experienced)?  Many outsources after five years are more expensive than in-house teams.  Off-shoring does take advantage of disparity in cost of living and labour market, but it has the downside of cultural and work-hours disparity, lesser security, and risky continuity.

#4           Outsources have better people.

The best people tend to be paid well and like being taken care of.  Many outsources do not hire the best people because those folks would make the labour cost go up.  Who makes a better burger?  The burger assembler at [fast food restaurant of choice], or James Beard?  (Beard is a renown chef and uses cream in his tasty burgers.)

#3           Outsources know the business.

An outsource might know their business, but do they know your business?  This is somewhat counter to core competency think.  To assume an outsource has the business knowledge in your field assumes that they also work for your competitors and/or have worked for you long enough to pick up your corporate knowledge.  Is every service desk or call center the same?  Not every application you use or product you produce is.   There needs to be a competitive differentiator somewhere.

#2           Outsources have deep benches.

It has been my experience that many outsources replace two-with-one, and not charge two-for-one.  Unless you offshore, the outsource is drawing from the same resource pool as your competition.  Why would you expect them to have better success at attracting and retaining resources given the cost pressure?  Benches get voided when there is a lack of work.

#1           Outsources follow best practices.

Outsources tend to do what they're contracted to do.  This is because most work needs to be billable, and strangely many best practices are not directly billable.  Take documentation for example.  It makes sense that an outsource would develop its own documentation and process models to help them service you better.  The reality is, it is not in their best interest, and they're not likely to share this learning with you anyway.  Best practices take time, even if the ultimate goal is eventually driving down the learning curve for the bench.  But figuring stuff out is directly billable.  A Tom DeMarco quote comes to mind: Crazy is repeatedly doing the same thing and expecting different results.

It comes down to core competency.  Does it apply?  It is rational to want to choose an expert to outsource work to that is their core.  At the same time, it is not rational to increase complexity in any system and expect a decrease in entropy.  Restated, you can't throw more uncertainty into the mix and still expect the whole thing to be predictable.  Predictable really means low risk.

Outsourcing is stupid.

A bold headline, isn't it?  If you define stupid as an act or behaviour lacking sense, then there needs to be a bit of context around this statement and justification to "Why outsource?"  "Outsourcing is Stupid" via CIOUpdate suggests why would anyone want to outsource IT when defects increase 35-to-40%?  For us old software engineering types, we were taught that defects found in the delivery phase of a project are 70-to-80% more costly to fix than those found in the specification and design phases.  That, and outsource projects tend to see project management and controls expand 25-to-30% that is a more expensive exercise.  The article goes on to state that the only effective reason to outsource IT is when a company cannot afford to do the work themselves.  To summarize the article, It is cheaper and better when you can do the work at home, especially when modern tools automate so much.

If you look at large companies, in particular resource companies, you can see a connection between the commitment of management to outsource, and the growth of the project management office.  With outsourcing, you tend to have management on both sides of engagement.  It seems like a lot of duplicated effort, logistical disconnects, and sacrificed quality for software and service provision that is 900% more ineffective.  These companies, like many large companies, have the resources to do the work themselves.

"When Outsourcing Goes Bad" from InformationWeek is a brilliant bit with more useful nuggets of information.  Of a survey of about 420 companies, only half ranked their outsourcing endeavours as successful.  One in six claimed their outsourcing was a disaster.  It makes sense though.   Many CIOs outsource for the wrong reason, and usually its not for increased efficiency (because how can you make that claim with all the evidence against it), but for that easy money reduction of operating cost.  This article mentions when IT is outsourced, the event itself requires board level scrutiny and continual review.   Many failures end up in costly litigations.  When the horses are out of the gate, the further they run, the harder they are to round up.

So again, why is it that companies that can afford to do it right, still pick the wrong path?   It can't be the core competency argument, because what large company would claim that their information systems do not present a material risk to their continuous operation?  So it must be ignorance, or skill-full politic in the deferring of blame.

And this reflects so poorly on the IT industry in general.  To reduce costs, you still need to go after the biggest spend that is your human capital.  When you outsource, the outsource absolutely will go for the cheap, warm body on the bench.  This continues to depress the job market and make IT an unattractive career.  And this in turn also drives the lack of credentials and experience in IT.

It would be so much better if continuous improvement, process efficiency, and quality control were the focus of solution delivery.  Execution excellence... how many companies have that sound bite in their mission or value statement?

Momma Don’t Let Your Babies Grow Up to be IT Guys

Momma Don’t Let Your Babies Grow Up to be IT Guys
Don’t let ‘em play with computers and install dual OSes
Make ‘em be doctors and lawyers and such…

I saw a report from the University of Alberta that showed the number of graduates in Computer Science have dropped from about 400 ten years ago to about 100 now.  This trend seems to be consistent across North America.  At the peak of dot com, it seems a ton of people flocked to the field.  They graduated about 2004.  And since then, youngsters just aren’t jumping to get in to Computer Science.

The noted Willie Nelson song is going through my head.  How many of us with Computer Science degrees who work in tech or software development would recommend our kids follow in our footsteps?  My six year old son recently said “Daddy, I want to do what you do when I grow up,” and without even thinking about it I said “No way.  Be a doctor or lawyer or something where you can use your brain.”

This thought has gone through my mind a few times since.  Somewhere along the way I have lost the passion I had for computer science.  Recently as part of my New Year’s Resolution I downloaded the development tools for Windows 7 Phone and made an app in short order.  I felt the surge of coolness and fun I once felt when building something new.  Then I looked at where I am in my career, and where my future is, and I became depressed.  I am a smart, knowledgeable fellow and my talents are completely irrelevant in my field.

The reason Computer Science is dying is because anyone can get into tech.  There is no bar, no standard, and no common ground.  The folks in tech are disposable.  As an undisciplined service industry, they are always screwing up.  So there isn’t much respect from other business folks for those in tech.  And I don’t blame those business folks.  It seems that many IT departments solely exist to be bottlenecks and are woefully misaligned with their business user's needs.  Vendors churn out crap that business users buy on the recommendation of their techies without much concern about quality or fit.  Tech zealots argue about tech-du-jour.  The Dunning-Kruger effect is everywhere.

Computer Science wasn’t supposed to be a path to a tech job.  It was a way to think.  Algorithms and data structures were cool.  Optimization and simulation were really cool.  But how often do folks apply the best-fit solution in their applications?  Or monitor performance after delivery?  Most times you just use a toolkit, or bang it out, because industry has come to expect crap that is just good-enough.  Version 1.0 is the last version.  And that guy with the 2 month programming course can churn out broken crap much faster and cheaper than someone who has a 4 year degree.   Then they're gone.  The direction from Project Managers, Business Analysts, and the like is the wrong direction, because those folks come from very diverse non-tech backgrounds.

So my recommendation to anyone who is considering tech as a career: don’t.  Go into environmental science, law, or dental hygiene…  anything but tech.  There is more job satisfaction saving the environment, standing up for people's rights, or making sure a person's teeth are clean and their gums healthy.

New Year’s Advice from the Armchair CIO

Bringing in 2011 I have high hopes for the IT industry. I've put together ten New Year's resolutions that I hope can help IT folks everywhere.

#10	Don't give up. You may be being outsourced. You may realize there is no career in IT. But if you can disconnect yourself from the insanity, you might be able to appreciate the comedy and enjoy the show.
#9	Do what you love. You might love tech, but be disillusioned by the industry. Make time for yourself to keep your love of tech alive. Try something new. Read a new book, or learn a new technology, or write that killer app, and enjoy the joy of tech.
#8	Work to rule. Why do the work of others for no credit? Training your replacement, or documenting everything you do so you can be replaced, just isn't worth it. No one will read those documents, and your trainee will forget everything after 15 minutes. Push back a little. Let other people do the jobs they're supposed to.
#7	Relax. Unless you work for yourself or a small company, it probably won't make a difference how hard you try. If it can't be done in 40 hours, it likely can't be done by killing yourself doing a 60 or 80 hour work week.
#6	Don't cast your pearls before swine. A Christian parable that means don't offer your valuable talents, information, or opinions to those that just won't appreciate it.
#5	Celebrate your moments. If you or your team has done something good, even if small in scope, go out and pat yourself on the back.
#4	Blow your own horn. Few people will blow your horn for you. Make sure people around you know what you've done (without being a braggart.)
#3	Don't be a hero. In general ordinary folks don't like heroes because the hero makes the ordinary folks look bad. When everyone is super - no one will be.
#2	Don't suffer fools lightly. Put silly people in their rightful place. Call a spade a spade.
#1	Treat yourself. It is important to geek out every now and then. Buy that 4G jelly drive, or that USB Fishquarium, because they're cheap and just so freaking cool.

I won't even bother reflecting on 2010. It was that bad.