h1

Requiem for a Metaphor

July 28, 2010

We use metaphors when what we have to explain may not be obvious. Given the complex nature of software, metaphors are used regularly. Every time you jump on your computer you are looking at different metaphors which come in the form of the icon. If you click on a folder icon, it’s not taking you to a folder; it’s taking you to a set of information. The folder icon is a metaphor for the organization of your documents. It is both a graphic element and a tool of information architecture used for better understanding. But, there is a problem sneaking up on us. Most of our metaphors are based in analog.

Many things no longer need to look like what they do. A television used to need a giant tube, which dictated its size and shape. Over time it got flatter. And then a lot flatter. Now a television has become a slim black box with a screen. Telephones have had a similar evolution. Once they were large devices that had a distinct look that was dictated by its analog nature. Now they’ve changed.

The convergence of devices on your average smart phone breaks metaphors like never before. It’s a phone, but looks nothing like the phones we grew up with. It’s a camera, but looks nothing like the cameras we grew up with. It runs applications, but looks nothing like the computer you grew up with. Given the newer technologies in development, your phone will soon become your wallet too. And for all it does, what does it look like? A slim black box with a screen. With this evolution we have lost inherit visual cues that analog gave us. This effects how we communicate in the digital space.

We are comfortable with using icons as a base metaphor for information on Web sites and operating systems. Look at the Windows OS. Your information and documents are subdivided into folders. But, if you look at how documents are increasingly digital, at one point you realize the metaphor of a folder may no longer be a logical reference.

If there are no paper documents, then there is no need for folders to place them in. At some point in the future, this will happen. With smart phones and digital readers, it may not be as far off as you think. The folder metaphor as we now know it will become an antiquated reference to how we used to do things.

The number of cell phone subscriptions will hit 5 billion this year. I would also argue the average icon used to represent a phone is outdated. If you do a Google search on phone icons you will see an overwhelmingly large number of images that have little to do with your average phone experience.

Holding on to these analog references makes little sense. Sometimes it’s the language that doesn’t add up. Tapes and VCRs have a rewind button, but so does you’re DVD player and DVR. It was called rewind because you were physically winding tape back to the first reel. The term fast forward is still relevant, but we should ditch rewind and call it fast back. Other analog references are less innocuous.

The accepted QWERTY keyboard layout is rooted in analog. It’s been arguably shown that other keyboard layouts are more efficient. But with the invention of the keyboard, they wanted to create something that was familiar and easy for those using mechanical typewriters. Now we’re stuck with it.

I am certainly not being nostalgic. I don’t want to be stuck with the old. I don’t want to cater to analog. I say good riddance, but it forces new questions to be asked. Abstraction is the removal of details. Digital has hastened the abstraction of these objects we create for ourselves. Fundamentally, it becomes a communication challenge. I see it as an opportunity for new language and new metaphors, but digital metaphors.

h1

Ideas Are Meaningless

July 12, 2010

A good idea can come from anywhere. People say it all the time because it is true. But, an idea by itself is utterly worthless without someone who knows how to take that idea from dream to reality.

Ever watch the television show House? Each week, Dr. House solves the latest medical mystery though an obscure idea that seems to approach him from anywhere or anyone. The “a-ha” moment that reveals itself does nothing more than point the way. It takes the doctor’s creative genius to recognize the idea when he sees it. And it takes his experience to make the idea a reality and actually solve the problem. Understanding the value of an idea is the first part of good creative direction. The second part is having the know-how to make it a reality. We are surrounded by ideas all the time. Recognizing value in a single thought floating in a sea of ideas takes not only creative intelligence, but experience.

Benjamin Franklin said, “At twenty years of age, the will reigns; at thirty, the wit; and at forty, the judgment.” As a young designer, I came about good ideas by spawning hundreds of bad ideas. I would push myself like I was at the gym. Just 4 more ideas, just 3 more ideas, 2 more, okay last ooonnne. Done.  Now in my thirties, I feel like good ideas happen more quickly. By comparison, they are certainly more clever. The difference is, I now see ideas through the scope of my experiences.

We see a lot of good ideas with poor execution on the internet. Actually, some studies have shown that people watching YouTube are turned off by high production value. I don’t know. Maybe free content needs to look like it’s free. I always ask, “could it be better?” How would you improve it? How could you make it more meaningful? In looking back at my blog, it’s no big surprise to me why some entries do better than others. It’s not only the quality of the idea, but the quality of the execution that counts.

Crowd sourcing uses submissions from an online community to solve a particular problem. This is probably the most literal interpretation of how a good idea comes from anywhere. The Pepsi Refresh project is one of the most popular expressions of crowd sourcing. This project not only outsources the generation of the idea, but the judgment of the idea too, through online voting. I feel like crowd sourcing is an interesting way to generate ideas. I am always willing to listen to anyone, but it’s the judgment aspect that I have trouble with. In the end, I feel like average judgment equals average success.

A lot of CEOs make unpopular decisions, only to become wildly successful. Sure, they could have done what everyone expected them to do. And that would have sufficed. But recognizing the value of a good idea, even when everyone else doesn’t, is a hard road to follow. You’re stamped with a lot of nasty labels until you prove your detractors wrong. The flip side is that, sometimes, unpopular decisions are just bad decisions. But that’s what makes it interesting.

Everyone has the right to their own opinions and ideas. In a professional setting, they have the right to express those ideas, or at least should be able to express them without fear of reprisal. But who makes the final call? There always seems to be some confusion surrounding opinions.

In the mind of a creative professional, there is a real separation between professional creative evaluation and personal opinion. Having an opinion does not qualify your average person for anything more than having an opinion. A creative director’s opinion reflects years of training. Sometimes it’s based on intuition, other times it’s easier to explain. They push to understand both failures and successes. This becomes the basis of a trained professional’s decision. A personal opinion is about what you like; a professional opinion is about what an audience will like. Sometimes it’s the same, other times it isn’t.

Creative evaluation does not come from having an idea or two. It’s about having thousands of ideas, and executing hundreds of them over years. A creative professional at an advanced level knows how to prioritize, evaluate and judge what is better. The process of raising an idea can sometimes be anything but lucid. It’s tricky to know when you’ve arrived at the right solution, but experience teaches you judgment. And that judgment is what gives meaning to an idea.

h1

Tell Them No, Just Never Use that Word

June 21, 2010

I was at an agency meeting some time back, when the head of the company addressed the sales team requesting they take programmers to client meetings as needed. It was at this point I witnessed a lead salesman turn to his colleague and say, “not a chance.” This event didn’t go unnoticed and got around the IT department fast which led to a few conversations. The one concern we got back from the sales team is that the IT people always say no. There is a solution to this, but we need to understand the problem first.

From the time we are little kids, we live in a world of no. No dessert until you finish your vegetables. No, you didn’t clean your room. There’s a lot of big frustration around such a little word. We all want to run around and do what we want. As children, the first part of being punished for misbehaving starts with your parents yelling the word no. It takes our heads out of the clouds and puts our feet back on the ground.

As adults, no gets internalized. We don’t kick and scream when we hear it, although that would be funny to see a board room full of executives “expressing” themselves. Under the calm veneer of professionalism, we are all emotional animals that get mad when we don’t get what we want. That’s not to say we are all boiling under an icy exterior, but telling someone no has real consequences.

No comes from the head, but goes straight to the heart. A programmer rationalizes why something can’t happen because of logically based perceptions. These opinions are not formed out of malice or petty dominance, but far too often are treated like they are.

Before you whip out the big N-O, remember it’s an emotionally charged and potentially damaging word. People are scared to hear it. In the world of business, you will be judged for using that word and the negativity will come right back at you. People will make up all kinds of reasons why you told them no without diving in to deeper issues. It can be a little ridiculous, but it’s the world we live in and we need to adapt.

There are ways to disagree without saying no.  And before you call me out on being manipulative, I am not advocating any level of political doublespeak and clever misdirection. Not because it doesn’t work, but because programmers are smarter than that and we don’t need to lie. So you take no out of your vocabulary, but what happens when you find yourself in a no situation?

The two situations I normally encounter are when requests are literally impossible to achieve and the other is when they makes no business sense whatsoever. Programmers are problem solvers. So use your talents and think about what can happen and what does make sense. Focus on the reasons why something won’t work and develop a solution that fixes those problems.

A common situation is being given an unrealistic deadline. So instead of saying no, tell them about what you can accomplish in that timeframe. Figure out how to stage multiple releases and let the client know that you will concentrate on getting the core functionality right. This helps the team focus on what’s important. If you come up with a better solution, everyone wins.

It’s an educational process that involves the programmers, account service, and the clients. Don’t be mad at them for not knowing. You have to educate them about what reasonable possibilities are and they will educate you about what their problems are. When you fully understand the problem, you should have the confidence to offer up an alternative if what they are asking for doesn’t make sense. And remember, you’re employment depends on your company’s ability to sell something. I would rather be coding than playing salesman, but a good team has to help each other out.

Sometimes a dumb request can be a smart one with a little work. And sometimes despite everyone’s best effort, our clients won’t be persuaded at all. Even if you fail, the best part is you learn what will and won’t work. In time you find ways to shelf the word no in favor of a conversation, at least that’s what works for me.

I love the responses I get from my posts. What I would like to do this week is for those of us out there who have had success in dealing with these situations to post how they handled themselves to help others who might be struggling. After a week, I will take my favorite top three and repost to the main blog as guest entries. Thanks!

h1

The Business of Beautiful Code

June 18, 2010

A little while back I had a technology director tell me it doesn’t matter how well code is written as long as it works without breaking and gets the job done on time. Why sweat it using complicated techniques that not everyone understands when there are more simple ways to do the work. After all, things can look the same on the surface regardless of it being well engineered or put together with duct tape and glue.

This guy liked the intellectually lazy, brute force approach. Don’t think. Just start coding now and get it done. Copy and Paste are now your two best friends. Well, mankind did build the pyramids with Stone Age technology. So I suppose there’s a lot you can accomplish with brute force, but I prefer to use my brain.

Writing software is a very creative discipline that requires a lot of abstract thinking about organization and performance. There are thousands of ways an application could be engineered. It first involves thoughtful planning at the beginning before a single line of code is ever considered.

Writing beautiful code is not just some nerdy game programmers engage in to see who can sit atop nerd mountain with their 4x scepter of insight. It’s about pure design that solves a problem. And there’s a real benefit to business. Beautiful code saves money. Beautiful code makes money. Ugly code gets work done quicker, but it’s like winning the battle, and losing the war. In time, bugs pop up and clients make changes that are impossible to accommodate. Sounds like time for an analogy.

Web sites and applications have a lot in common with cars; they both have a purpose and a personality. Just as we judge a car as being good or bad for a multitude of reasons, we can draw our analogy from these similar evaluations.

A car is designed around the driver, but for many it’s what’s under the hood that counts. Engines can be a mystery though. Sure, people get the basics, but it takes a mechanic to be able to take it apart and put it back together and an engineer to create one from scratch.

When we run a piece of software we look at obvious performance issues. Does it run? How often does it break? Most people you work with will get it up to this point. And from what I have seen, they only care about it up to this point. But, what about real performance?

In the automotive world, performance is well marketed to consumers. They take a certain feature, give it a name, and tell the consumer to want it. Traction control, dual overhead cams, and fuel injection are sold to the public regardless if they have a clue about what it means. The car nerds understand dual overhead cams makes for a more powerful engine. The general public just knows it goes faster.

Beautiful code is high performance. And everyone wants that because it’s faster. Google markets their speed. Type in any topic and you will see at the top of each page a list of how many things were returned and how fast you got them. It’s really impressive when you stop to consider how much data is being sorted to return relevant information. It doesn’t matter if you are writing code or building an engine, you can’t get good performance from a lack of engineering. Speed is good, but maintenance is even more import.

Cars are expensive to maintain and so is software. A study conducted by Human Factors International found that 80% of software life-cycle costs occur during the maintenance phase. Okay, cars aren’t as expensive to maintain as software, but you get the point. Well written software is designed to be updated, changed, bitch-slapped or whatever. It should take it like a man. There are real financial consequences when code takes a long time to update. It can even cancel a project. What I have noticed over the years is regardless of what I am told; I always end up having to go back into something to make edits. As important as this is, there is one more reason why the quality matters.

If an engine is well built, you can put it in several other cars. Good reusable code works the same way. If it’s done well, it can be placed in many applications. There is a business law that states the cost of products and services go down over time. It’s called the experience curve. Businesses find cheaper and quicker ways of getting the work done. When a cheaper way to do business is found, a company charges less to increase volume, or operates with higher profit margins. Either way competitors are adversely affected. Beautiful code can become that competitive advantage to manage the curve.

It’s all about money. It usually is. Ugly code may look like the practical choice. It’s an easy solution when you become defined by deadlines. Some programmers work that way, but surviving isn’t thriving. For businesses to grow and stay competitive they have to have a culture that prizes beautiful code.

Follow

Get every new post delivered to your Inbox.