jump to navigation

We Forget What We Don’t Use April 17, 2018

Posted by Peter Varhol in Software platforms, Strategy.
Tags: , , ,
add a comment

Years ago, I was a pilot.  SEL, as we said, single-engine land.  Once during my instruction, for about an hour, we spent time going over what he called recovery from unusual attitudes.  I went “under the hood”, putting on a plastic device that blocked my vision while he placed the plane in various situations.  Then he would lift the hood, to where I could only see the instruments.

I became quite good at this, focusing on two instruments – turn and bank, and airspeed.  Based on these instruments, I was able to recover to straight and level flight within seconds.

My instructor pilot realized what I was doing, and was a lot smarter than me.  The next time, it didn’t work; it made things worse, actually.  I panicked, and in a real life scenario, may well have crashed.

Today, I have a presentation I generically call “What Aircrews Can Teach IT” (the title changes based on the audience makeup).  It is focused on Crew Resource Management, a structured way of working and communicating so that responsibilities are understood and concerns are voiced.

But there is more that aircrews can teach us.  We panic when we have not seen a situation before.  Aircrews do too.  That’s why they practice, in a simulator, with a check pilot, hundreds of hours a year.  That’s why we have few commercial airline accidents today.  When we do, it is almost always because of crew error, because they are unfamiliar with their situation.

It’s the same in IT.  If we are faced with a situation we haven’t encountered before, chances are we will react emotionally and incorrectly to it.  The consequences may not be a fatal accident, but we can still do better.

I preach situational awareness in all aspects of life.  We need to understand our surroundings, pay attention to people and events that may affect us, and in general be prepared to react based on our reading of a situation.

In many professional jobs, we’ve forgotten about the value of training.  I don’t mean going to a class; I mean practicing scenarios, again and again, until they become second nature.  That’s what aircrews do.  And that’s what soldiers do.  And when we have something on the line, that is more valuable than anything else we could be doing.  And eventually it will pay off.

Solving a Management Problem with Automation is Just Plain Wrong January 18, 2018

Posted by Peter Varhol in Strategy, Technology and Culture.
Tags: , ,
add a comment

This article is so fascinatingly wrong on so many levels that it is worth your time to read it.  On the surface, it may appear to offer some impartial logic, that we should automate because humans don’t perform consistently.

“At some point, every human being becomes unreliable.”  Well, yes.  Humans aren’t machines.  They have good days and bad days.  They have exceptional performances and poor performances.

Machines, on the other hand, are stunningly consistent, and least under most circumstances.  Certainly software bugs, power outages, and hardware breakdowns happen, and machines will fail to perform under many of those circumstances, but they are relatively rare.

But there is a problem here.  Actually, several problems.  The first is that machines will do exactly the same thing, every time, until the cows come home.  That’s what they are programmed to do, and they do it reasonably well.

Humans, on the other hand, experiment.  And through experimentation and inspiration come innovation, a better way of doing things.  Sometimes that better way is evolutionary, and sometimes it is revolutionary.  But that’s how society evolves and becomes better.  The machine will always do exactly the same thing, so there will never be better and innovative solutions.  We become static, and as a society old and tired.

Second, humans connect with other humans in a way machines cannot (the movie Robot and Frank notwithstanding).  This article starts with a story of a restaurant whose workers showed up when they felt like it.  Rather that addressing that problem directly, the owner implemented a largely automated (and hands off) assembly line of food.

What has happened here is that the restaurant owner has taken a management problem and attempted to solve it with the application of technology.  And by not acknowledging his own management failings, he will almost certainly fail in his technology solution too.

Except for probably fast food restaurants, people eat out in part for the experience.  We do not eat out only, and probably not even primarily, for sustenance, but rather to connect with our family and friends, and with random people we encounter.

If we cannot do that, we might as well just have glucose and nutrients pumped directly into our veins.

The Evolution of Software Delivery January 25, 2015

Posted by Peter Varhol in Software development.
Tags: ,
add a comment

This could alternatively be titled “Is Desktop Software Dead?” I’ll start at the beginning. Circa 2000, we delivered software in 12-18 month increments. It was desktop software, intended to debug and test Windows (and Java) applications, and manufactured and delivered on CDs and DVDs (don’t laugh; back then, even Microsoft delivered its MSDN entirely on DVD).

Our customer thought we delivered new versions too quickly. It took too long to install software on individual machines, and they didn’t want to do it that often. For the most part, they wanted to upgrade when Windows changed or Visual Studio changed, not when we wanted to push out new software.

Circa 2010, I attended a talk given by Kent Beck, in which he described how software delivery was speeding up over time. He examined how software testing and delivery would change as we accelerated to quarterly, monthly, weekly, and even daily deliveries. And he delivered this entire talk without once using the word agile.

There is a key factor missing in this story. That is that the type of software we produced for desktop computers ten years ago is no longer relevant. Sure, I still run MS Office, but that’s more of a reflex action. I could be using Google Docs, or Open Office, or something like that. The relevant software today is web, or mobile, or some hybrid of either or both that may also put something on my laptop.

In other words, the nature of software had changed. When we had to physically install it on individual computers, delivery was an annoyance for the users, to be avoided (tell me about it). They ultimately didn’t want our upgrades unless they absolutely needed them.

Today, for users, whether they are businesses or consumers, delivery has to be invisible. And, as Kent Beck described, done much more rapidly, perhaps almost instantaneously.

There are some tradeoffs to this model. There may be new features that could be difficult or unintuitive to use, and require instruction and training.

And it poses challenges for software teams. Agile and DevOps addresses some of these challenges, but delivery is an entirely different ballgame. Teams have to be able to quickly assess the quality of the updates and be able to roll back if need be. There has to be communications between IT operations and dev and test in order to make this happen.

Design a site like this with WordPress.com
Get started