Simply Amazing September 11, 2009
Posted by Chuck Musciano in Technology.Tags: Best Of 2009, Corn Maze, Simplicity, Technology
2 comments
It is the time of year that corn mazes become popular. People will pay to wander through a maze cut into a corn field, enjoying the fall weather while they try to find their way in and out. I always naively assumed that corn mazes occurred almost as an afterthought to the process of raising corn. At some point, I supposed, a farmer rode through his fields with some sort of mower, carving out a maze. I was markedly incorrect.
Corn mazes, it turns out, are a big business. Mazes are laid out before planting begins, and the actual cutting is often controlled by GPS-directed tractors. Maze designs are marketed by various companies and can cost many thousands of dollars. In my area, farmers join maze co-ops that control where mazes are created, ensuring that each maze has a strong local market to drive revenue. Within the co-op, mazes are not located closer than 30 miles from each other to reduce competition. Non-co-op mazes pop up, of course, but they do not get the other benefits of belonging to the co-op.
Who knew? How could such a simple, all-American thing like a corn maze actually require so much complicated planning and forethought?
It turns out that almost every “simple” thing is actually quite complicated, behind the scenes. In fact, the best simple things are just a front for very complicated systems and processes. From clean running water and electricity to your iPod Touch, there are many layers of detail that you just don’t have to worry about. Thankfully, I might add.
IT is no different. There are many complicated layers to even the simplest of IT tools and systems. Ideally, those of us in IT should be masking all that from the end users, providing a simple tool that does something well. Unfortunately, we generally do a terrible job of hiding complexity from our end users. Sometimes, we think we are doing them a favor when we expose complexity in the form of “features” intended to help them. Instead, we generate more confusion and annoyance.
It is unfortunate that people know what a “404” error is or that disks must be defragmented. My mom should not have to know that software is updating itself or that the printer heads need to be aligned. People want to use computers to get something done, not to become more proficient with computers.
I have no idea, honestly, how to do anything with my car except to start and drive it. I like looking under the hood to admire the engineering therein, but heaven forbid that I would do anything under there. I am not an automotive engineer, and I don’t want to be one. I just want to drive a reliable car.
I think those of us in IT lose sight of what users really want. We forget what it is like to really be an end user. Even as we build wonderful new systems, we need to keep our users’ real goals in mind. They just want to enjoy the maze. They don’t want to know how to grow corn.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio103″ only_single=false]
Passion Or Vocation? August 5, 2009
Posted by Chuck Musciano in Leadership, Technology.Tags: History, Mentor, Passion, Technology
8 comments
In a recent issue of Technology & Invention magazine, Mara Vatz wrote about discovering her grandfather’s engineering textbooks from the 1930s. Herself a recent engineering graduate, she was struck by the difference between those old books and those she recently used. Her grandfather’s books were filled with the passion of engineering, of being consumed with the excitement of building and creating, of bending the natural world to the will of man for the betterment of society.
Her books, in contrast, were dry and methodical. They taught engineering as a sequence of steps that could be applied to solve a problem. They presented engineering as a vocation, just a job, just some rote sequence of steps far removed from the real world of problems to be solved. The contrast made her sad, longing for a time when her chosen profession seemed more alive to its practitioners.
I have the same worry for the world of IT. At the risk of cementing my geezer status, I learned computing in a time when everyone wrote assembly code. I punched cards and booted machines by toggling switches on the front panel. I learned how to build computers from the transistors up, wire-wrapping individual logic gates to decode address lines. It was fascinating, consuming, and instilled a passion for technology that I carry with me even today.
Are we instilling the same passion today? Or has computing become a vocation, a series of steps that you use to solve the problem at hand? I am certainly not advocating a return to assembly code, but I want to make sure that our newest computing professionals have that same gleam in their eye as I did so many years ago. The layers of abstraction we’ve built in our systems enable us to create systems that were inconceivable back then, but those same layers remove us from the nuts and bolts of computing. As those nuts and bolts fade away, our true understanding of computers fades.
Some of today’s IT people have that passion. You can see it in your best people, the ones who dig in and never let go of a issue, who wake up at 3 AM with the answer to a problem, who run into the office with the next great idea. But does everyone have that passion? And if they don’t, should they?
I want everyone to have that passion. Passion is infectious, and passionate people in IT create passionate people outside of IT. If people didn’t find that passion in school, we need to pass it to them ourselves.
Much is made of leadership and mentoring, teaching important skills to our teams. Beyond leadership skills, we need to convey the passion of our field to our people. We have to constantly demonstrate our love of this stuff, the wonder of a problem solved, the satisfaction of a user helped. If we aren’t going to get excited about a new tool, and our people don’t get excited, how will we engage our users?
My passion is for computing, of course, but this applies to every discipline. Do you have a true passion for what you do? Do you demonstrate it every day? Do you infect your people with that passion and enable them to carry it to others? Or is your job just a vocation? If so, I’ll bet your people feel exactly the same way.
Shaking The Mouse July 13, 2009
Posted by Chuck Musciano in Leadership.Tags: Coaching, Operations, Technology
6 comments
Back in the mid-80s, optical mice made their first appearance. Unlike their roller-ball brethren, optical mice used light reflected off a special mouse pad to detect mouse movement. They were cutting-edge and fun to play with.
In my research group, our Sun workstations used these optical mice. One day, a sales rep was in our lab demonstrating some software package, when the mouse stopped responding. Nonplussed, she held the mouse upside down, shook it, and resumed the demo. Our slack-jawed stares caught her attention, and she explained how the mouse “got clogged” every now and then, and shaking it “cleared the mouse” and helped it work again.
Now, it was true that the Sun optical mouse driver did hang every so often, but it was due to a small input buffer being overrun with too many mouse events. If you waited a few seconds, the buffer would drain and the mouse would recover, no shaking necessary. This woman, however, believed that mouse was clogged and that shaking was required to fix it. It clearly worked: every time she shook the mouse, it started working again.
Determining the root cause of a problem and applying the right solution is a crucial skill, whether you are debugging hardware or solving personnel issues. Our brains are so desperate to correlate cause and effect that we are easily convinced that some action, no matter how odd, really can solve a problem. Even worse, as soon as we find what seems to be the solution, we stop looking for the real problem.
In the case of the mouse, some simple analysis of what could actually clog a device with no moving parts might lead you to conclude that something other than shaking was at the heart of the solution. For larger problems in more complicated systems, it can take weeks and months of digging to find the true root cause. But if we do not find the real problem, we are doomed to experience it again, compounded with the frustration that our “solution” is somehow not working. A technical problem is not fully solved until you can connect the dots from the very first event in the failure to the very last element of the repair.
People problems are far harder to debug. Unlike computers, people are non-deterministic and prone to sudden erratic behavior. For many issues, we may never know why someone really made a particular mistake or acted in a certain way. In many cases, the behavior is not repeatable, so our solution cannot be fully tested. Nonetheless, we are duty-bound to explore as many avenues as possible to make sure we understand why people act in certain ways and how our own behavior can affect others.
Technical or personal, it can be tempting to grab onto the first potential solution and stick with it. It’s certainly easier than digging and digging to prove that you solved the problem. But how many times are we left implementing bad ideas or half-baked systems because we didn’t dig as hard as we should have? Are you really getting to the heart of every issue in your world, or are you just shaking the mouse?
Get It In Writing April 13, 2009
Posted by Chuck Musciano in Random Musings.Tags: Management Skills, Project Management, Technology, Users
1 comment so far
When I worked in R&D, we shared our building with another group whose job was to improve engineering productivity. They took their job quite seriously and had a mandate to investigate any aspect of the engineering groups that appeared to be in need of improved productivity. They weren’t engineers, but they did claim to understand process and project management, and they often used a new acronym, TQM, as a sign that they were on the cutting edge of this kind of stuff.
As you can imagine, the engineers were not overly enamored of this group. Fortunately, the productivity team must have decided that our R&D group was beyond help, productivity-wise, since my group was rarely the target of their attention. On the whole, our groups got along pretty well and often shared information.
At some point, a few folks from the productivity group got involved in a fairly elaborate project, working with another division in my company. They were very excited about this project, which involved some fancy new computer system to collect and analyze a lot of data. The more this woman talked, the more excited she got about the project, and the more doubtful I became of her chances of success.
After a bit, I asked her about system performance. The data volume was large and the analysis was complex. Even with the best current technology, a functional solution would be a challenge to build. Would the system be able to perform well? Would the users be happy with response time?
She didn’t miss a beat. “Of course, it will perform well! We wrote that into the requirements!”
And off she went. With the stroke of a pen, she had solved any and all performance issues this new system might have. As you might imagine, the project never finished, for a variety of reasons.
It is easy to listen to this story and laugh at the naivete of non-IT people. How could anyone design such a complicated system and them make it perform well with a simple written requirement?
The deeper lesson (you knew there would be a deeper lesson, right?) is that someone failed to educate this person as to the real complexity of her project. Non-IT people cannot understand what we do. Unfortunately, when we do it well, we make it look very easy. When it looks easy, people assume that it is easy and base their world on that assumption. This results in projects that fail to meet user expectations.
Users do not want to know the details of our technology. But they need to know when things are really hard or really expensive. If they probe, you can explain why. We owe them enough information, matched to their curiosity, so that they can appropriately plan and manage their world. If we fail to do that, we have failed them, no matter how well our technology works.
The Effective CIO 