(The green arrows point to empty shelves.) The store was still open... this isn't a shot of the employees packing up, but rather a shot of some guy hoping to find something to take home. And keep in mind that this guy probably already has at least five t-shirts he got for free this week.
Yes, I think this is all the evidence we need of Java's continued success. People were snapping up any Java or Duke-branded thing they could find, from mugs to shirts to pens to really expensive things like the leather Java jacket.
I'm making light of this -- after all, they're just t-shirts. But take a moment to think about why attendees -- Java developers, mostly -- couldn't spend money fast enough on Java-branded items. What does that say? And you might think you're immune... that people buying this stuff are idiots. That you wouldn't have spent good money for stupid shirts and mugs. But lots of us did. The only reason I didn't spend more myself is that they ran out of the really cool "thrasher Duke" shirts that featured Duke skateboading down Lombard.
If buying logo items is any indication of how developers feel about Java, and I think it is, Duke has a very healthy future ahead of him, and we can rest assured that the Java community is still vibrant and active and most importantly, can still afford t-shirts.]]>
* Number of t-shirts I was able to get in one pass on the show floor: 5. Without really trying. Surely the improvement in booth giveaways means something. It's not like the old days, but last year, I swear I was lucky to walk away with a white paper.
1) JBI - foundation for SOA (so popular in fact, that they're repeating it. Too many people wanted in but were turned away).
2) 1.5 Language Features
3) Josh Bloch's famous puzzler session
4) EJB 3.0
5) Next generation web services
6) JAXB
So, the Java Business Integration thing was the #1 most popular session yesterday.
Today, the "Java at the movies" session on the Blu-Ray spec was completely full, door closed, turning people away. I reckon it was one of today's most popular sessions.
* Day one's top-selling books at the show bookstore:
1) Java puzzlers
2) Swing Hacks (Yay! Java on the Desktop obviously lives)
3) Maven Developers Notebook
4) Head First Design Patterns
5) Hibernate in Action
6) JBoss 4.0 official guide 7) JBoss Developers Handbook
8) Spring in Action
9) Java Language Spec, third edition
10) Refactoring
11) Spring Live
12) Killer Game Programming in Java
What can we infer from this? Not sure, but notice that the word "hacks" and "killer" are both in the list. And both Spring and JBoss each have two books in the list.
Stay tuned for results of tomorrow's "cool hunt".]]>
We imagined a world where Java was in devices, and while the whole toaster and Java Dog Collar thing didn't happen (thank goodness), Java is in billions of devices, with millions of dollars being made from downloadable Java-enabled content. We aren't wearing our Java rings (although I still have mine), but Java is the smarts inside a gazillion smart cards (and at least one Boeing airplane).
We imagined a world where Java was THE client-side web language, and while that didn't work out, Java ended up playing a much more substantial web role, powering the world's most heavy-duty enterprise server-side apps.
Of course we all wanted Java in gaming consoles, and that hasn't gone quite as we'd hoped, but now the Blu-Ray standard means Java will be inside virtually every next generation DVD player! Downloadable AV content, it seems, could be an opportunity even greater than supplying downloadable mobile device content. It could happen.
We imagined a world where JavaBeans (remember 1998?) were going to be The Thing, and everyone and their grandmother would be able to use a simple authoring tool to wire up an app (complete with multimedia) in no time. That didn't happen, and for a while it looked like the JavaBeans team went down to something like... 1/2 a person. But now 2005 is starting to look like 1998 again, only this time they really mean it. NetBeans is seriously rocking, and the client/desktop component model is showing up in all kinds of JSRs and tools. Sun's damn serious about adding those 5.5 million more developers, and they're pulling out quite a few stops to lure (or as Gosling put it last night, "seduce") them in with friendlier tools.
And color me naive, but I honestly believed it when Scott McNealy said -- and this is pretty close to an exact quote -- "We're absolutely committed to Jini, and supporting the community like crazy." He went on to explain that there's just so many things to talk about, and so much noise, that he and Sun haven't been doing a good job at talking about Jini (duh!), but that he wanted to do more. And he did, starting with saying, "Jini, Jini, Jini" into the mic.
He talked about how much Jini is used internally, and I suddenly remembered that four years ago (when I was a Sun employee) I wrote a Jini browser, and when I finally got it working I suddenly "discovered" all kinds of Jini services the storage guys were doing somewhere on campus. I was so thrilled to find real services to list in my toy browser that I never stopped to recognize that these services the storage folks were doing were serious Jini apps. (I, on the other hand, was building Really Important Applications like the Jini-enabled virtual pet kennel).
Anyway, all the optimism here at JavaOne doesn't mean we aren't a little more jaded, skeptical, and rational than we were in 1997, but when you look back over the last ten years, Java has changed the world. And y'all are a part of that.
(The highlight of the first day for me, though, was seeing the bullet point on the Mustang Features slide that mentioned wildcard classpaths. It's amazing how much applause one simple little asterisk can generate...)
So just pause for a moment and let it sink in how far we've come in ten years. Then try to project ten more years into the future. If the next ten years are anything like the last, then whatever you're imagining is surely an understatement.
Stay tuned...]]>
The room was packed. A guy got up to ask a question at the microphone about generics, and Gilad's reply was something like, "We've been talking about that here for the past 8 years... let's move on." Gilad assumed that we'd all been not just coming to JavaOne for the last 8 years, but that we'd all been participating actively in the discussion and progress on adding generics to Java.
The next guy at the mic carefully prefaced his question with, "I'm sure everyone else here has been keeping up on this for years, but this is my first JavaOne and I haven't been following it..."
Gilad's response was enough to guarantee that only the brilliant--and more importantly--long-time Java developers asked a question. Oh, and you had to be 100% current, too.
It wasn't just Gilad making the assumption that virtually everyone at JavaOne had been writing Java code, like, forever and had long sense grown bored by the older JSRs they'd obviously memorized.
I believe there's a disconnect summed up in two big myths:
=======
FACT A: In the last two years, the number of programmers using Java grew by 50%. At JavaOne in 2003, Scott McNealy announced there were 3 million Java developers, and today he's claiming 4.5 million. So a huge chunk of Java programmers have been at it for less than two years!
FACT B: Tim O'Reilly and co. have been analyzing book sales data (not just O'Reilly books, but all technical books) to use book sales as a technology trend indicator, and one of the things they've comfirmed in the data is that as a programming language matures, the book sales for that language shift from advanced to beginning books. Today, most of the top-selling Java books are targeted at beginners, while five years ago that wasn't the case. The number one selling Java book since 2003 is for brand spankin' new first-time Java programmers.
I reckon this is somewhat intuitive--when a programming language is new, you get the "alpha coders", but as the language matures, most of the people coming in are those trying to learn it for the first time, and tend to be mere mortal geeks--regular folks--who might need more help. People like me, for example, who don't dream in binary and usually prefer a little more handholding when transitioning to a new language (or for some, into programming for the first time).
And don't forget that when the alpha geeks were there in 1997, remember, Java had fewer than 300 classes in the standard API! There was a whole lot less to learn then, so the barrier to entry seemed lower.
(Although there were far fewer resources with which to learn, not to mention that large parts of the API didn't actually work, so perhaps that balances it out. Less to learn, but more to work-around. I can remember having to roll my own scrolling text box in Java 1.02.)
Anyway, this latecomers-are-regular-folks thing maps well to the Technology Adoption Life Cycle fleshed out in Geoffrey Moore's book, Crossing the Chasm.
My conclusion? Within another 18 months or so, half of all Java programmers will be relatively new to the language.
=======
FACT: I don't actually have a fact, but I'll bet you a microbrew that even here--on java.net where we come specifically because we do want to keep up--many of you harbor the dirty little secret that you're not as current as you could be. That you know more about Mustang the car, then the next version of Java. That there are still a few things about generics you don't actually know. Or worse--that you're still on Java 1.4!
Worse still, that you don't even understand the new naming/numbering/version scheme and whether it's Java 1.5, Java 5.0, or why there's still a Java 2 in there somewhere. (Just kidding, it's obvious that even Sun doesn't fully understand it, so I reckon we're all off the hook for that one, and Sun has promised to announce some new naming/versioning plans at JavaOne).
=======
I started this post by speculating whether Java is still friendly for newcomers, but perhaps the bigger question might be... is it still friendly enough for those of us who aren't?
Personally, I was burned on that whole beta EJB 2.0 spec fiasco, where it changed quite dramatically at the very end. Many of us spent months trying to come up to speed on an approach that was eventually (and thankfully) scrapped, but it was changed only after the point at which we thought it was safe to start learning the spec. Yes, it was beta... but when it gets close to final, usually you feel pretty safe. I learned my lesson, though, and now I rarely bother to spend my precious brain bandwidth (in my case, an extremely limited resource) on anything that I might have to unlearn when it shifts.
No, I'm happy to stay blissfully in the dark on most things, until the time is right and the resources are stable enough to jump in and learn it cleanly and efficiently. And although I might be wrong (and you'll tell me if I am), I don't think I'm alone on this it's-not-like-I-don't-have-too-much-to-do-as-it-is thing.
Perhaps we need a self-help group:
"Hi, I'm Kathy, and I don't keep up on all the beta specs."
There, I feel better already.
Yes I do understand and appreciate that there should be plenty of advanced sessions for those of you who have (and it's often the BOFs that fill that role best), but I hope that the average session (not explicitly marked "advanced") does not come loaded with the unspoken prereq that I've memorized every relevant JSR. By the way, for those of you secure enough in your geekhood to admit that you, too, don't always keep up, I'll be blogging some Cliff's Notes-esque highlights of JavaOne. : ) ]]>
I don't think it's that simple.
There are a bunch of somewhat-related issues I could play with, but for this blog I'm narrowing it down to:
1) The notion of "pick the best tool for the job".
2) The notion that the "coolness" of your tool is not important (and that it may be detrimental to *want* your tools to be cool).
The rule that says mature, responsible programmers "pick the best tool for the job" makes a lot of sense, of course, but in practice very few can (or *should*) live by it. Obviously for most of us there are tradeoffs we have to consider:
* If you aren't already experienced in the "best" tool, there could be a substantial learning curve. So you weigh the benefits of using the tool against the loss of productivity while you come up to speed. The arguments to this are usually something like, "Well, a good programmer would spend time trying to learn as many languages as possible so that his toolbox is bigger." Which brings up another tradeoff:
* Even if you DO have a big toolbox, the phrase "jack of all trades, master of none" comes to mind. There will always be only a very small number who can not just learn but *master* multiple languages, and KEEP their high level of proficiency. So we weigh whether the additional gains by the tool being a somewhat better fit are wiped out by the fact that your ability to exploit that tool are much lower than another, less suitable, tool that you're particularly brilliant with. Which brings up another tradeoff:
* Context-switching isn't free. Each time you switch to another language, even one you know, there's still a certain amount of mental and physical overhead. Reloading the rule set for "working with this language" into your brain can be costly, and with it comes the reloading of your support materials. Even something as simple as rearranging your reference book shelf is a potential hit. Then there's figuring out where to get support -- which website forums, etc.
These are all the standard points, of course, that have been discussed to death already:
But this really leads me to the whole coolness thing. Those in strong support of always picking the best tool argue that when people are in love with their tool, there's the "everything looks like a nail" syndrome. That if they become so enamored with the cool factor of their tool, they'll do whatever is needed to slap the tool into submission just so they can continue to use it on problems far better suited for some other tool.
Is that SUCH a terrible thing? Taken to the extreme, yeah. Trying to do architectural drawings with a crayon is pretty lame, and doing the equivalent with software development tools could really hurt. But there's a big difference between using a tool that's simply not the best fit for the job vs. using a tool that's clearly wrong for the task.
So if you can assume that perhaps being in love with your tool isn't the end of the world, as long as you don't take it to the extreme, and assuming that your tool (like Java) is capable and powerful and works *well* (even if not always the best) for the widest range of problems you're faced with, then what else can we consider about coolness and being in love?
(First, yes I am making the assumption that people who really care about the coolness of their tools are also likely to really love those tools. I love my Mac. I even love my cool skis. And yes, I still love Java. Could be a girl thing, sure, but I've been around enough men in my life to know they're just as capable of feeling the "L" word for their [insert cool gadget including stereo system, car, guitar, power drill, espresso maker, golf clubs, tivo, etc.])
But first, I'll argue that if tool coolness really didn't matter--that it was about what cool things you could DO with it, rather than its inherent coolness or sex appeal--then why does it matter in so many other areas? We are emotional creatures, even when we claim to be logical and rational. If the coolness of our tools didn't matter, we'd all be driving (forgive the phrase) "butt-ugly" cars. Things where not an ounce was spent on design or aesthetics or coolness, so that it could all be spent on things like safety, reliabilty, efficiency, etc. After all -- if the goal is to drive to San Francisco, then THAT's the "cool thing we can do with it", and all we should be concerned about, right? The tool we use to get there is not what matters as long as it's the "right tool for the job" and in that case the right tool would presumably be the one that would get us there with the least amount of pain and expense. And iPods certainly wouldn't be dominating the mp3 player market. And about a zillion other products that rational left-brained engineers buy would look different and be purchased with different criteria.
Coolness matters.
The psychologists and neurobiologists tell us it matters even when we kick and scream and claim it doesn't. Our brains betray us under the scrutiny of an fMRI scan, where parts light up when we see something beautiful or sexy. (There's a whole other issue about WHY we perceive certain gadgets as "sexy", but I won't go there.) The point is, sexy and cool matter to us at our core, as human beings. We cannot escape it. Sure, we can work to "fight" those impulses... but I remember attending a sales training course a decade ago where the teacher's first words were, "The biggest misconception people have is that *consumers* buy emotionally while *business* customers buy on logic. The fact is, EVERYONE makes decisions with an emotional component, it's just that with business customers you have to provide the facts they need so that they can justify their emotionally-made decision and continue to delude themselves that they made The Rational Choice." Think about all the things you've bought in the last year where you told yourself a really good story to justify it..."The extra pixels on that 23" display will make me more productive." and "No, seriously, this car has a better resale value. It's an investment."
I think I mentioned in an earlier post how Don Norman, usability guru, was once known for strongly advocating ease-of-use over aesthetics, smugly deriding designers for choosing, say, "sleekness" over ease. And of course even HE has somewhat changed his message -- although he still demands usability, he is (passionately) acknowledging that the emotional aspects of design DO matter. A Lot. (And since I have a rule that says I must try to work in something related somehow to Jini with every post, don't forget my favorite geek book of all time, Gelernter's Machine Beauty).
Cool matters to you. Get over it. It's just part of what makes you human. ; )
But now we come to the Big One. The reason that coolness SHOULD matter: Passion.
Coolness (or just perceived coolness, it really doesn't matter) is linked to passion. The cooler you perceive your tools to be, the more passionate you are about those tools. And passion, while it might lead to the "everything is a nail" syndrome, has an extraordinary amount of value!
Obviously there's quality of life... a life with passion is certainly more fun than one without. And the more passion, the greater the chances that a person has what psychologists label optimal experiences. And the more optimal experiences one has, the more likely one is to describe life as being "happy". So, passion = optimal experiences = happiness. And research says happy people are generally more productive. Certainly they're more spirited and fun to be around...
But that's still not the Big One. That people are happier in their life is just a nice side-effect. After all, plenty of people believe that you do some things for money (work) and then you do some things for the chance to express your creativity and passion (hobbies). Hugh Macleod refers to it as the sex and cash theory. Many people believe that it's naive and immature to expect your job to offer self-actualization and personal fulfillment, and that you're on your own for THAT. Of course the level of enthusiasm and passion on java.net means I'm largely preaching to the choir here; although there's still a division between people who are passionate about the things they create using the tool vs. the tool itself. And often, that distinction really doesn't matter. If you're passionate about doing the work, that's the real key.
Still... here's why having a cool tool DOES matter:
Think about how people behave when they're passionate about a hobby or cause. They read about it voraciously. They stay up late at night trying things. They seek out others who share the same passion. They're always trying to get the latest and greatest. They're excited. They try to go from user to power user to master.
Tool coolness can increase the chances of the tool user becoming passionate. And when the tool user is passionate, all those other good things happen. As a manager, I'd much rather have employees who wanted to learn more, stay current, be excited about learning cool new things, etc. rather than the kind for whom any spare time is spent on their *real* things they think are cool. More importantly, as a product *creator* (and this is where we ALSO come in as developers), I'd MUCH rather have my customer/users be passionate about my product. Then I don't have to resort to advertising gimmicks, since word-of-mouth from people who are passionate is unstoppable and the greatest marketing power today.
Can this be dysfunctional? Of course. Passion can become an unrealistic obsession. But that's the exception, not the rule. And of course we DO hope there's a certain amount of fickleness over the long run... that we don't just say, "this is the only tool I will ever love for the rest of my life." In other words, we hope people can become passionate about multiple tools, even if that passion is sometimes serial as they leave one behind when finally seduced by the newer, still COOLER tool...
I guess I could summarize all this by saying that the idea of tool coolness is *not* disrespectful to the professional community of software developers, but just the opposite. That by working to make a tool cool, the tool itself becomes an object of excitement, enthusiasm, and passion. And THAT has value all by itself. So coolness for coolness sake really DOES matter, because it ulimately ripples throughout someone's daily life in ways that can seriously matter. People have changed careers and lives based on a tool that was just cool enough to spark the light that eventually became something much richer and deeper. I do believe that building tools that give someone the power to do something cool is the most important goal, but often the best way to help make that happen is to make the environment in which they do those things... cool. So I'm not really addressing whether Java IS or IS NOT still "cool and sexy" (personally, I think it is.), because that's a personal choice. But anything any of us can do to try to inject coolness into the tools that WE build (as Sun can and sometimes does with Java), can actually help make the world a better place. : ) (She says, typing this on her very cool G5 iMac while listening to her very cool iPod through her very cool stereo and googling on the very cool saddle she wants to get for her very cool Icelandic horse, and grateful for everyone who helped create these things.)
I feel very lucky indeed that the things I'm paid to do are also the things I find really cool. If we can make that happen for other people, by building the tools WE develop with an eye towards the cool factor, they'll thank us.
(And if anybody involved in the creation of the iPod, or the new iMac G5, or Adobe InDesign, or the J2ME Wireless Toolkit (although I'm still pissed you aren't supporting Macs), or Jini happens to be reading this, thank-you!)]]>
The assumption is this: Paired Programming is a Choice.
In other words, most people seem to believe that whether you participate and thrive in a paired programming environment is a personal choice. And the sub-assumption is that if you do NOT, well, you clearly have a personality defect. Most of the debate goes something like this:
I don't like the idea of Paired Programming.
That's because you haven't tried it. You're just afraid to try something new.
No, I really DID try it.
You obviously didn't try it RIGHT. I'm sure you missed some key point about how to do it.
No, I was in an XP shop that had been doing it for a long time, with a lot of success.
Oh, so it's YOU that's the problem. Yeah, XP really smokes out who is and is not capable of being a good Team Player. Must be an ego thing.
No, I've always considered myself a really good team player and collaborator. I get high marks for this on every performance review I've had... from every manager I've had, and I've never had any trouble working well with co-workers.
Like I said, sometimes it takes XP to smoke out who is REALLY a Team Player. There's no room today for loners.
I know the arguments for and against XP, and I'm personally in favor of most of XP. I know the case for Paired Programming. I know the benefits. I know the studies and real results. I also know that for most people, Paired Programming really is a choice. That's because most people fall into the category known as Non-Loners. The masses. The majority.
But there is a minority (and they can't just be defined by a simple Meyers-Briggs type) for whom the idea of Paired Programming is NOT a choice any more than is their sexual orientation. People for whom the idea of being Not Alone that much (and with someone with whom they do not already have an intimate relationship) makes them as crazy as being alone makes Non-Loners, well, lonely.
One problem is that the majority world of Non-Loners largely views Loners as maladjusted. A condition to be "fixed". The "L" word has been perpetuated, especially by the media, to represent something sad, or worse, scary. On any given day, somewhere in the world (especially the US) a reporter is saying, "Neighbors describe the [mass murderer, pyromaniac, etc] as a loner." In reality, most of these so-called evil loners were in fact Non-Loners who were rejected by others and didn't take it well.
Loners are the folks for whom being alone is not a condition to be avoided, but relished. For whom a Thanksgiving day spent hiking alone, coding a game, or reading a good book is far preferred to a day spent locked in a house with ten bickering relatives. Yet the Non-Loners of the world find it inconceivable that a holiday spent alone could be anything but a cause for pity. Loners not only don't mind, but in fact have a strong need for, being alone. How do I know? I am one. And the idea of Paired Programming, in it's most-common implementation (you sit side-by-side, physically together, headphones off, for the majority of your programming day) makes me physically ill. Not because I'm afraid of something new. Not because I insist on personal code ownership as opposed to collective code ownership. Not because I just haven't tried it (I have). Not because I'm not a Team Player. Not because I have a Serious Character Defect. (OK, that last part is debateable but still...)I simply NEED to work alone (which doesn't have to mean in my own office or anything... I can be alone sitting three feet from someone else) for larger portions of the day than the traditional Pair Programming model allows. For me, this is a need, not a choice. And please don't suggest that I have no self-awareness... most True Loners have fought the masses and the negative stereotypes long enough to know the difference between a need and a choice. We're the ones who who have to risk the life of another person (as in, "You'll kill your Aunt Betty if you don't come to the family reunion...") to protect our own sanity.
Non-loners experience real, physical symptoms of lonliness when forced to spend too much time NOT in the company of others. They become stressed, depressed, anxious. Loners, on the other hand, experience physical symptoms when they they don't have enough alone time. For us, time-without-company (espcially company not of our own choosing) is as necessary as water and oxygen. Not a habit. Not something to be learned. Not a choice.
However, the True Loner is definitely in the minority. So I believe an XP manager should spend time and energy to smoke out which of the reluctant programmers really ARE merely afraid vs. True Loners. In most cases, it's the former, and a gentle introduction is probably all that's needed. But ignoring that True Loners like me exist won't make us go away. And you're more likely to find the True Loner in the programming profession than, say, marketing.
We exist. The question is, what will you DO with us? Do you force us until we either numb ourselves to the overwhelming togetherness or just leave because we can't stand it? Do you find other tasks for us that aren't on the project? Do you fire us for non-compliance? Or do you find a way to exploit our strengths?
I'm not sure what the answer is. As a manager (and I was always a really bad one), I'd probably be tempted to say sacrifice the one for the many. But does that really, in the long run, serve the company and the team best? Is there really no other way to get the benefits of XP Pair Programming than by this particular (sit side-by-side, etc.) implementation? Because True Loners aren't against team work and being with people. Heck, I sit five feet away from my co-author/partner all day long, every day. It works GREAT for us. This does NOT violate my sense of aloneness, and we collaborate throughout the day, brainstorm, review each other's work, etc. A True Loner doesn't need or necessarily want to be in Solitary Confinement. And again, please don't confuse being a Loner with not being a team player. These are two completely different things. The majority of people are Non-Loners, and you'll find plenty of non-team-players among those ranks.
Part of the reason I felt compelled to post this is because True Loners by definition don't "stand together". There's no group advocating for the Loner. We don't get together with others of our own kind. We don't form clubs. We don't have meetings. But my heart nearly breaks for the True Loner not just forced but often humiliated into participating in Paired Programming, lest he or she be viewed as Not A Good Person. Which means, Not Like Most People. For most Non-Loners (except those that have come to know and appreciate a Loner), the True Loner simply does not represent Goodness. Non-Loner == Good and Normal. Loner == Trouble.
If you are (or suspect you might be) a True Loner, you might consider the book Party of One: The Loner's Manifesto. If you're a manager, and you suspect that you might have a True Loner in your midst, or you're perhaps in a relationship with someone you think might be a True Loner, you can read the book to learn more about us. To see that we're not evil, stuck-up, cold. We're just different. If you're a Non-Loner with negative feelings about True Loners, perhaps it's because you're afraid of something new? ; )
And maybe you wouldn't have wanted any of these folks on any team of yours, but the world is filled with examples of True Loners who made a difference in the world. As "Party of One" author Anneli Rufus puts it in the book, "Down the years, around the world, they form a shining line -- in single file, of course. Da Vinci. Michelangelo. Issac Newton. Rene Descartes. Issac Newton. Kipling. Thoreau. Beatrix Potter. Dickinson. Lawrence of Arabia." She later includes Alec Guinness and Albert Einstein. Do we have anything to offer the project, even if we can't survive Paired Programming? Maybe not. But this passage from Rufus makes me feel better about it:
"Yet here we are, not sad, not lonely, having the time of our lives amid their smear campaign. We are the ones who know how to entertain ourselves. How to learn without taking a class. How to contemplate and how to create. Loners, by virtue of being loners, of celebrating the state of standing alone, have an innate advantage when it comes to being brave;; like pioneers, like mountain men, iconoclasts, rebels and sole survivors. Loners have an advantage when faced with the unknown, the never-done-before and the unprecedented. An advantage when it comes to being mindful like the Buddhists, spontaneous like the Taoists, crucibles of concentrated prayer like the desert saints, esoteric like the Kabbalists. Loners, by virtue of being loners, have at their fingertips the undiscovered, the unique, the rarefied. Innate advantages when it comes to imagination, concentration, inner discipline. A knack for invention, originality, for finding resources in what others would call vacuums. A knack for visions."
At least that's what we True Loners like to believe when we're labeled at best "not a team player" and at worst, "an axe-murderer". Besides, we're cheaper in the long run. We rarely stay for the pizza and beer parties. ; )]]>
Wear Your Good Shirt
Face it--how you look does matter. In fact it matters more now than it did before, as we've evolved (for better or worse) into a Culture of Style. The bar has been raised; your target market (not that you should refer to your prospective date that way, but still...) expects more than just functional today. Look at the iPod phenomenon. Dozens of devices play mp3's, and for less money, but people keep choosing sleek and sexy (or today, colorful) over purely functional. In other words, you can't just get the job done--you need to look good doing it.
Now, before you flame me about how surely Ease of Use (and ReUse) is more important than Look and Feel, keep in mind that the two aren't entirely orthogonal. The most successful designers, engineers, and architects in the world understand that beauty lures the user into the experience in a more intimate, engaged way. Quite possibly my favorite geek book in the world is Gelernter's "Machine Beauty" where he explains "how beauty drives the computer revolution: how lust for beauty and elegance underpinned the most important discoveries in computational history and continues to push research onward today."
And come on--can you honestly say that you have never looked at some code, an algorithm, an API, an implementation, or a UI and used a word like "elegant", "sleek", "slick", "cool", "beautiful", or "sexy"? We're human beings, and we're genetically programmed to respond to beauty. Give someone an ugly-yet-functional application or API and they might find it perfectly acceptable, but they won't have that transcendent experience.
In a previous blog about API design, I suggested Don Norman's book The Design of Everyday Things.. And in that book he claims that there's no excuse for making something hard to use. But some of his proposed solutions are a little, well, unattractive. In fact, he rails on engineers and designers for making something look slick (like by using fewer buttons and instead making the existing controls modal) at the expense of usability. And I agree. But why should it have to be an either/or choice? Usability/functionality vs. elegance/beauty? And even Don Norman admits now that it's time for products that will "appeal to the emotions as well as to reason". His new book Emotional Design is driven by his goal to make products more alluring. He says, "For years I worked hard to ensure that products were usable. Now it is time to make sure they are pleasurable as well. Usable, effective products need not be ugly or dull. So, I'm on a campaign to ensure that our products have beauty and emotional impact as well as effectiveness and understandability."
But wearing your good shirt isn't just about looking good--it's about showing respect for the other person. How would (or if you've got some experience with this, how DID) you feel if your blind date couldn't be bothered to even find something clean? Besides, first impressions tend to be metaphorical... I just got off an airplane a little while ago coming back from the Software Development conference. The airplane seat back tray table was a little dirty, and that always makes me wonder, "What else didn't they maintain on this plane?" (a comment which made fellow java.net blogger Sue Spielman say, "Remind me never to sit next to YOU on a plane"). If your code, API, interface gives users a first impression that you didn't take the extra care to make something look decent, that sets the tone for how they view everything they see of yours after that. And it takes a lot more work to undo a first impression.
OK, so does this assume that every product, bit of code, interface, or API has to conform to some extremely high, fully-accepted standard of beauty? To bring this back to dating, does that mean every male must look like he stepped out of the pages of GQ, and every female the pages of Vogue? Of course not! No, I said, "Wear your good shirt", not "Look like a model." In other words, pay attention to aesthetics. Put it on your priority list. It's about acknowledging that the end-user has an aesthetic sensibility, and putting some effort into making what you've got appealing.
Don't Assume You'll Never Have Competition
You can get away with ignoring the "Wear Your Good Shirt" rule while you have no competition. If you're the only member of whatever sex the datee is looking for, it might be less a factor. If you're the only API, product, framework, game in town, for example, you can probably survive and even thrive being sloppy and unattractive. But what happens when you're no longer the only player in the field?
Don't Be Fake
Don't act like you're one thing and suddenly become another. Be honest. Be real. Be yourself. We've all seen software that starts out nice and friendly, and then switches into something different. A long time ago, there was a comparison made between the Macintosh OS and Windows, that went something like this (can't remember the exact original), "With Windows and the Mac OS, it's like you're in a lovely lobby of a nice hotel. But with Windows, you can make one wrong turn and suddenly find yourself thrown into the boiler room." Being clean and honest is better than being a poser. Brenda Laurel, in her book, Computers as Theatre believes a software system should always "stay in character", and that the end-user should be able to rely on what the system initially appears to be.
Be Fun. Be Someone Others Want To Be With. Don't Be Negative.
I wrote my first book using the publisher's Microsoft Word template. I was depressed for about six months. I sat five feet away from my co-author, also working in Word, and I had to listen to him swear several times a day. When we started our next book, we switched to InDesign. And the world brightened. The weather was always a little sunnier. More flowers bloomed in the yard. The pets and kids were better behaved. Of course, this assumes that InDesign was suited for our particular task, and it was, beautifully. But wow--it was like falling in love.
Make a list, even a short one, of the products, APIs, frameworks that made you happy. That made you think, "This is awesome. This is perfect." Now make a list of the ones you struggled with (I'm wildly speculating that this second list will be, um, longer). Next time you design and build something, try to focus on having that thing end up on someone's "made me happy" list. You'll have their undying loyalty and respect for life.
It's Not About You.
Who would you prefer to be with: someone who you are impressed with, or someone who makes you impressed with yourself? Someone who makes you think, "Wow, that person is so much better than I am." or someone who makes you feel, "I rock!"
You know when you're around someone special when they bring out the best in YOU, as opposed to leaving you in awe of who THEY are. When you feel good about yourself, and your capabilities. On the other hand, the people you're less likely to date are those that leave you feeling somehow less capable. Less smart. Less attractive. Less clever, less interesting, less... you get the idea. Way, way too many APIs, books, products, interface, programs, seem designed to get the user to recognize how smart the designer was, when the most appealing products should leave the user recognizing how smart the USER is. If the API you design leaves the programmer feeling frustrated and stupid, they'll run like hell the next time they're given a choice between something that you've designed and something from another candidate. And we all know that lowering someone's self-esteem is NEVER a good recipe for bringing out someone's finest work.
So don't focus on what YOU do... focus your energy on that other person. Paste a picture of him or her (and if you're building for a large unknown group, just pick a picture of someone who represents a member of that target group) on your monitor. Always remember that your work is about THEM, not YOU. Instead of thinking, "What cool thing can I do?" think, "What cool thing will my work let him do?"
Be Polite.
Your mother warned you about good manners. Imagine you're on a first date and suddenly the person you're dating just gets up and walks away, without a word. No indication of where they're going or when they'll return. Ever had a software app do that to you? The little things like progress meters REALLY matter. If you don't think it's good to be rude, then don't have your software apps be rude either. Let people know what's happening. Reassure them. Reduce their stress.
There are a lot more I could add here, like "Be Memorable. Be Engaging. Be Interesting. Be a Good Listener.", but I think the main point I'm trying to make is that crafting something that another human will use should be taken as seriously as any other important human interaction. I'm often shocked at how people will pull out all the stops to try to impress a prospective mate, but appear to care less what their end-users think and feel. Of course, I'm guilty of the same things and no shining example myself. This is something I personally have to work on every step of the way. I DO wear my good shirt on a first date. Yet I've found myself making excuses for errata in a book that with a little more effort I could have prevented.
But I think there's a fairly simple solution, and it gets back to the first blog I made here--make the receivers of your product or service humans. Not abstract "users" that appear on a report somewhere. Not abstract "customers" or "programmers", but REAL living breathing people. Find ways to force yourself to see those who receive your work as individuals with needs, concerns, issues of their own. You KNOW how it feels when you do something that delights someone, right? Like, when you cook something for someone (which in my case, is limited to grilled cheese and pancakes, but still... I'm brilliant at them), and you watch their face intently as they chew the first bite. You're looking for that little smile... that subtle way their face lights up and you know you've made them happy. Think about the ways in which someone else's pleasure makes you feel good. If you can truly conjure that sensibility when you're designing a product or API, you'll have to hire a bodyguard to fight off the rabid fans.
I'm serious about the picture thing. I pasted pictures of customers in my cube. I made a sign when I was at Sun that said, "Someone just paid $3,000 for my service. Was I worth it?" and eventually I started seeing those same signs tacked up throughout our building. (With some minor word changes, although I can't understand why... ; ) And if you're a manager, encourage your staff to watch video tapes of REAL people or better yet, TALK to real customers. Last time I blogged about this someone commented that if management is doing their job correctly, workers shouldn't have to have any contact with customers. In other words, the spec should say it all. But what I'm talking about goes beyond the cold, hard, specification and into the realm of emotions and beauty and passion.
I have to believe that if I had a webcam at home, and the developers of Adobe InDesign could watch me at work, it would make them happy to hear me say, "I LOVE this program!" at least once a day (and this is after more than a year of full-time use). That doesn't mean that I don't have some issues and complaints, but as it is with any worthwhile relationship, when you're head over heels in love, you don't dump them just because they don't meet every possible need.
Perhaps instead of reading so many technical books, developers should go back and ask their mothers for some good old fashioned dating advice. And hey, just because you're already in a long-term, committed relationship doesn't mean you should take ANYTHING for granted. Imagine how delighted your long-term partner would be if you came home one day acting much the way you did back in the days when you were still trying to impress them ; ) Just because you've got customers you don't believe can, or will, go anywhere else shouldn't be an excuse for slipping on the fundamentals. Putting a smile on someone's face can be so easy... you can usually delight someone simply by doing just a tiny bit more than they expected. Imagine a world where we all work just .01% harder at trying to put a smile on someone else's face : )
]]>But I'll just mention one idea: APIs should not be exempt from fundamental usability principles. I'm coming from the selfish perspective of one who has to actually learn to *use* these things, and, more recently, as someone who has to try to help others do the same. And if for no other reason than to make myself feel better, I'm going to suggest that if you have real trouble working out an API and you're thinking that it REALLY shouldn't be that hard... perhaps it really isn't YOU. So before you start questioning how on earth they ever gave YOU a PhD in astrophysics when you can't even work out one frickin' interface, take a deep cleansing breath and repeat this little positive affirmation: "It's not me. I AM smart. I have the
It's easy to rail on API designers when you're on the other side, I know. I've personally authored some of the most unreadable and unmaintainable code in the history of software. But at least I have the decency to feel guilty about it, especially after having spent a few years studying usability and learning theory. I don't want to single any group out, but I have to make at least *one* example; it's from the EJB spec (which, don't get me wrong, I LOVE. It's perhaps one of the most reader-friendly specifications to come from Sun).
Usability principal: Things which behave differently should look different.
This is fundamental user interface or product design 101. Humans will assume that if two buttons share the same shape and color, for example, that they'll generally have the same kind of behavior. So product designers are expected to do things like, "Make the navigation buttons look and feel different from the control buttons..." One of the worst violations of this is in products which use the pure evil of "modes". You know what modes are--where a button is overloaded so that in one mode it does THIS but in another mode it does THAT and... Donald Norman (who recently spoke at the Emerging Tech conference) writes fabulous books, at least one of which should be REQUIRED reading for every programmer: "The Design of Everyday Things". He does a great job of letting you off the hook by explaining how it's not your fault you can't work that device, and that product designers are either being lazy or trying too hard to save money by making fewer buttons.
Example API violation: lifecycle callback methods for Entity and Session beans.
When I try to help someone learn EJB, I spend way more time than I should with things like, "What's that? Why is there an unsetEntityContext() for Entity beans but NOT for Session beans? Oh, because you have to have a callback for when the bean instance is being destroyed. What? That's what ejbRemove() is for? Oh, no, that's just for Session beans. With Entity beans, ejbRemove() means "delete from the underlying persistent store", so... since ejbRemove() was given a profoundly different meaning for Entity beans than what it means for Session beans, well, they had to have something else to call when an Entity bean instance is about to die." And then do all that again with ejbCreate(), of course. (And don't forget that both ejbRemove() and ejbCreate() have corresponding methods in the client interfaces... remove() and create(), which also share these differences.)
According to usability fundamentals, giving the Entity bean interface the same methods as the Session bean interface, but giving those methods completely different meanings, adds MUCH more cognitive strain than if developers simply had to learn two totally new method names. You simply can't wrap your brain around learning that a set of methods does one thing for this object, and something drastically different for this other, very closely related, object. In other words, they made ejbRemove() and ejbCreate() use modes! If you're in Entity mode, they mean one thing. If you're in Session mode, something different. Not that we all don't *get it* and remember it, eventually, but it takes longer and we could be doing other more important things. Like skiing.
Again, I feel a little bad picking on this one example from EJB, especially when there are so many other things I really like about that spec. But it's the one that's caused me the most frustration, because I have to go through this process of helping people learn—and then unlearn/relearn—these methods every time I try to teach EJB.
Now, for some APIs it probably is just a question of better docs. But better docs wouldn't help the fundamental problem of something like modes, so better docs isn't the solution for everything.
My suggestion is that each and every programmer be strapped into the Don Norman Appreciation Chair and forced to read "The Design of Everyday Things". It's fun, fascinating, and enlightening. I have a whole book list after that, but I'll save those for later. My goal in life is to make MY life as easy as possible, and I truly believe that if everyone pitches in, you'll really help me out on that. Because unlike so many of you, I am one of those unfortunate souls who is NOT a quick learner. If not for speed dial, I wouldn't be able to call home. Imagine how long it takes me to memorize well-designed and well-named APIs, let alone the truly confusing ones...
]]>Yes, this is an old debate (I like what Simon Phipps had to say after JavaOne), but my being on the receiving end of some of the anger is still kind of new to me, so I'd like to hear more about what's driving this mini-backlash against the new wave of books and developer tools intended to bring the not-quite-C++-gurus into the Java fold.
Is this in fact "dumbing down" and de-valuing the Java language and/or de-valuing Java programmers? Should we (Dori and I, and all other folks who try to teach Java to others or who build tools like Project RAVE) deliberately impose artificial barriers to entry to help guarantee that only the best and brightest can ever write Java code?
Is it really true, as some claim, that managers everywhere are going to snap up these one-step-beyond-supersizing-it programmers and toss out all the ones with real knowledge and skills? Is it true that if one needs a gentle introduction (or at least a different *kind* of introduction) to, say, the world of OO development, that it means he has no hope of ever becoming good at it?
Is there no way a Java developer can be any good without a CS degree? (Although there's always a certain amount of snobbery on both sides -- the CS grads (who may not have had real world experience) vs. the hard-core real-world vet who doesn't need no stinkin' degree.) Is there only one True Path by which a human can become a good Java programmer? And if there is, WHO decided what that path was supposed to look like? Is it possible that the path looks like that simply because... well, simply because it always HAS looked like that?
I might be kidding myself, but I like to think that *anyone* who is capable of learning to do this, and has the passion and interest in working at it and growing and improving, deserves the chance. Just because someone needs (or maybe just WANTS) an easier, brain-friendlier way to get started doesn't automatically mean that person is an idiot/dummy. And it doesn't mean that this person is doomed to write terrible code for life, bring large-scale projects to their knees, and signal the final dealth blow to the careers of seasoned developers.
OK, it sounds like I'm being melodramatic, but these are almost verbatim statements I've heard. But the weirdest thing for me is that some of the more vocal complainers I've heard from act as though they themselves were *born* with their knowledge and skills. But once upon a time, they too were absolute beginners. Everyone has to start somewhere.
Roger Schank, one of my favorite AI professors (founder of the Cognitive Science Society, former director of the Yale Artificial Intelligence Project), claims that the whole approach to teaching (and especially technical subjects) in higher ed in the US is almost completely contrary to everything we know about how the brain works. He claims (and the learning theories certainly seem to back this up) that students learn *in spite of* the ways in which complex subjects are taught in school, rather than *because of*. So, why do these methods still persist in universities? He believes there is a certain amount of, "Well, *I* had to suffer through it like that, and by god, SO WILL MY STUDENTS." And the whole thing just propogates forever, including extending into corporate training.
I guess I'm really bringing in multiple arguments here, so I'll try to summarize the main questions I have:
* Is it wrong to make it easy for those without a formal CS background or years of programming experience to learn Java and/or OO?
* Is it wrong to make learning a complex (and serious) technical topic *fun*? Does it degrade the topic? Does it degrade/insult those who worked hard to become expert at that topic?
* Now that just about all C/C++ programmers already know Java, who are these next 7 million going to be?
* Assuming there *is* at least *some* danger (and I believe there is) that some will come in to programming jobs lacking the understanding and appreciation we know they need, is there something we can do?
* In other words, rather than complaining that these next 7 million are going to be our downfall, can we take steps to help the new folks learn and appreciate more of the art and craft of OO development?
These new folks are going to need not just some "how-to" skills, but also "what-to" and "why-to" and "when-to" understanding. I'm not buying the whole sky-is-falling idea, but still, the concerns aren't completely without a basis. So, what can we do to help?
]]>But man oh man is it ever fun! The MIDP 2.0 Game API is so easy to use. In about 15 minutes after flipping through the API and the MIDP spec, I built a multi-frame animation, fully user-controllable, with automatic double-buffering, in about a dozen lines. And that 15 minutes includes creating the graphics! Until I started playing with it, I really had no idea how simple and clean it is to use GameCanvas and Sprite.
Of course, developing and deploying games for *real* devices is a *lot* more involved--I'm just using the emulators that come with the Wireless Toolkit. But I'm paying attention to the JTWI spec and trying to work within the constraints recommended for portability. And there's that little issue of, well, virtually no devices in the US that currently support MIDP 2.0. Still, I haven't done something so quickly and simply since the old Applet days. Except that was Java 1.02, when I had to walk uphill in the snow both ways to do my own double-buffering and, oh yeah, roll my own scrolling text area because the original one in AWT didn't exactly *work*.)
And it's a walk down memory lane, too. I'm looking at the new MIDP 2.0 Style Guide, and I could swear I'm reading word for word some of the things we used to all do and say about writing games 10 years ago--reduced indexed color palettes, extreme caution with object creation, putting up a splash screen while you wait for your first offscreen buffer to be displayed... but it's great fun and so satisfying to use the Wireless Toolkit--you get instant gratifcation. So different from writing enterprise beans or even servlets/JSP. You sit down at your editor, and a few minutes later you have this cool thing running in your choice of faux phones. (Although I have NO idea what's up with that scary-looking thing in the toolkit they call the "querty device". Yikes.)
So here's the part that sucks--NO SUPPORT FOR MAC OSX! Yes, you can do MIDP development on the Mac, with a little effort and configuration, but you cannot run the Wireless Toolkit. And apparently the Borland tool is no longer supported on the Mac either. In fact, there are apparently NO useful J2ME development environments for OSX. That just sucks. I *did* manage to get the Wireless Toolkit to run under Virtual PC on my Mac (thanks to Michael Yuan for letting me know that he got it running, or I wouldn't have tried). It's painfully slow, of course, but no slower than my ancient PC. And all because of one small piece of the toolkit that's apparently native? I've talked to Ariel, the lead developer of the WTK, I think, and he was happy to hear I had it running under Virtual PC, but did not know of--or have plans for--a Mac version. (He's still my hero for making the toolkit, though). I talked to the "Java guy" at Apple (Dan Steinberg introduced me to him at MacWorld, but I forgot his name) and Dan and I both made our points about wanting J2ME developer support on the Mac. I'm sure tons of other people have complained about this... I know there have been other blogs here and on O'Reilly about it. But I just thought I might as well add my own special way of complaining. : )
It's so easy to get started playing around with MIDP 2.0, that I don't know why more folks aren't trying it out. It takes, like, five minutes to install the toolkit (45 minutes if you have to first install Virtual PC on the Mac!), and you're good to go (all you need to do is tell it where your JDK lives). After that, it's so simple to write, build, and run (in emulation) your first little app:
1) Launch the KToolbar part of the toolkit. It comes up immediately with a little window and waits for you to Create or Open a project.
2) Create a new project just by giving it a name for your project and a class name for your MIDlet.
3) Most helpfully, the tool builds a complete directory structure for you in the "apps" directory within the toolkit home. It makes *everything* you need, and even tells you where to place your source file.
4) Open your editor and type in a little MIDlet (a class that extends MIDlet). These are tiny little things, mostly, with lifecycle callbacks that work much like applets. There are plenty of examples that come with the toolkit. Be sure to name the class with the name that you specified when you created the new project.
5) Click the Build button. Really. That's it. It compiles your little MIDlet and (assuming you don't get compiler errors) it's ready to run.
6) Click the Run button. Up pops the default, garish-yet-somehow-stylish emulated phone. You'll see your project name and a "launch" button. Select the "launch" button and there you go! Wow!
7) Oh, you made a mistake and it doesn't work correctly? No worries. Change your source code, hit "save" in your editor, and click Build again. It really is that simple. Geez. Compare this to the steps to try even the simplest bean or--these days--even a simple web application requires some effort to configure and deploy into Tomcat correctly. Yes, we have Ant scripts for everything, but there's just a hundred and one picky little things that can always get you, especially when moving to a new machine, new version of Tomcat, etc. But this Wireless Toolkit, well, like I said--instant gratifcation.
The best news today seems to be that most developers doing MIDP development *are* in fact doing games. Small games. That means that some lucky folks are doing real-world development where you can have a complete product built and delivered in a week or less. Yeah, there are plenty of headaches for those doing real deployment, but these Java-enabled devices finally *are* starting to appear now, even in the US, in a Big Way. (Sure, 2.5 years after it was announced at JavaOne that these days were just around the corner, but still. It HAS finally happened.) And MIDP 2.0 support can't be *that* far behind.
So if you just want to have some fun, and who knows -- maybe soon you'll have a chance to work full-time or even just on the side on some little mobile device games--download the Wireless Toolkit and play. It's the least painful New Java Thing To Learn that I can think of, and it'll help you get your simple game chops back. Lunar Lander. Asteroids. You *know* you used to make those things when you were *really* supposed to be studying for midterms...
Besides, *small* things are now culturally popular. There's the Mini Cooper. The new iPod Mini. And there's Mini Java. (Yeah, yeah, I know it's MICRO, but "mini" is cooler.) So I'm now unofficially insisting that J2ME is Java 2 Mini Edition.
]]>
Life's better when I'm motivated and passionate. And yeah, sometimes it's *easy* to stay enthused, like when I worked as a game developer. But as much as I deeply appreciate enterprise Javabeans, as an EJB developer the most thrilling part of writing and deploying a bean for me was coming up with a JNDI name (and we had a naming convention anyway, so that pretty much sucked the creativity out of *that* decision). So when I moved from doing fun GUI things (which I loved) to doing server-side enterprise things (which I, well, did *NOT*, unless it was Jini, but that's a whole different story), I had to find my own ways to stay pumped up. I don't mean pumped up for *life*-- that's what skiing is for. I mean pumped up for *work*. I'll be damned if I'm going to spend 7 to 12 hours a day with no passion. Life's just too short (or is it too long? I can never remember which one works best here) to spend that much time without this level of excitement.
So I go to conferences. That's *my* way. I've been doing it for the last 15 years, and it has always been worth every penny (although I try desperately to get my employers, when I'm employed, to pay for them).
Do I go to learn? Yes, but that's not my main goal. I go to become swept up in the enthusiasm. To risk my life trying to catch the t-shirt tossed to the crowd at the end of the demo. To see the dog walking the floor with a webcam on his back.
I'd love to hear about conferences (or any other events or activities) that get YOU excited, but here are my all-time favorites:
MacWorld San Francisco.
The Game Developer Conference (I don't care WHO you are, or whether you have ANY interest in building games, you'll still love this one)
JavaOne (duh)
GeekCruise (to be honest, this is one I have not paid for myself... I went as a speaker)
Siggraph
Now, I have to say that my experience with a conference will be very different from someone else's... a lot of people don't like JavaOne, for example. But I always go in with the attitude that I WILL get something beneficial from the show, by allowing myself to be caught up in the excitement. I don't go in with the expectation that I'm going to learn a gazillion killer tips and land a new job/promotion/raise. Last year's JavaOne, for example, was worth it just to hear Josh Bloch do his "Tiger, Tiger Burning Bright" poem. Not as cool as a Coldplay concert, but this guy has a lot of fans (me included), and most of the (standing room only) folks in the room were pumped up about Tiger after that. And yes, that enthusiasm fades as you get back to your cube and realize you have still MORE to learn (and still no time in which to learn it), but I believe that in some dark corner of your mind, that sense of excitement still hovers, waiting for you to encourage it. To water it and keep it alive.
To rekindle the flame and help remind you why you DO love Java, and why writing Java (even if it's not what you get to do on your day job) makes you part of a very exciting group. ; )
So, some might say that it's an employer's job to keep that spark going, by paying for the development of the developers. And I believe that this is one of the best investments an employer can make. But I'm not willing to make my level of personal passion dependent on my employer. Yes, my employer DOES benefit by the enhanced quality and productivity and creativity that comes from my having attended these conferences, both from a learning-new-things and feeling-more-excitement perspective. But if my employer's too short-sighted to see that, I'm doing it anyway. I'm doing it for the quality of MY daily life.
And to get the latest iSkin for my iPod (in a shade of blue that matches my eyes, of course).
]]>Nice, that. When they don't have to see or talk to customers, they can tell themselves happy little stories like, "This is what our customers want." or "It's not our fault." Meanwhile, those of us who *did* face the customer, almost daily, took the heat. Sure, these other employees heard about quality problems--reports were generated each month, and groups with especially poor quality were "spoken to". But I was astonished by just how poor the quality had to be before it was considered unacceptable. And sure, there were plenty of regular reports with titles like, "Voice of the Customer", where we were given info about what the customers (faceless and nameless) supposedly said and wanted. But there was no *real* voice (the kind you could actually hear) behind the report. No real human with stress of his own. No person whose life we were actually affecting, good or bad.
It seems that as long as customers remain some abstract concept and not real living, breathing, humans, people can justify an awful lot of crappy quality. Meanwhile, the folks who *do* interact with the customer are often among the lowest-paid (receptionists, customer service, entry-level tech support, etc., phone order processors). Hardly anyone ever paid attention to what these folks had to say, and instead listened only to others of their own kind... the kind who did lots of Really Important Work in a nice, hermetically-sealed customer-free environment. No messy clients to get in the way of the real work.
The most depressing part of this story is that the facility where these folks worked had customers in-house virtually every day. Lots of them. If only the employees would walk the 400 yards or so down the main campus hallway. But I decided that if I couldn't bring the employees to the customers, I'd bring the customers to the employees. At least in video. So I grabbed someone with a video camera, and I randomly asked some customers if they'd spend five minutes and let us interview them. Nobody refused.
At first I thought, "Oh, this'll be perfect--these customers will complain and that'll *really* show these employees the negative impact of their work, and that should motivate them to improve. They can't just throw their work over the fence and forget about the impact." And then I began the interviews. Did the customers complain? Oh absolutely. Clearly. Explicitly. "Yes!" I thought, "This is good stuff. This will work."
But then something else happened during the interviews.
Something completely unexpected.
Without prompting, many of the customers insisted on explaining the ways in which the products and services had affected their lives in a *positive* way. In a heartfelt way. In a few cases, a life-changing way! These were living, breathing humans... with more than just a checklist of complaints. They had fears. They had stress. They had dreams. I caught them on camera talking about how this particular service had given them a new direction in their career. One guy said that he never imagined he'd be able to accomplish the things he could do now that he had one of our products, and you could almost see his self-esteem ratcheting up. One woman claimed that a week working with the training and support staff had taken her from hyper-anxiety to relief and hope that things in her work life would improve in ways that truly, deeply mattered to her.
My first reaction was to edit the hell out of it. "Gotta take out that positive stuff", I thought, "that will only *encourage* the employees to continue what they're doing, and make them think there's no need to improve."
But then I wondered... while attaching a name, face, and voice to a customer *complaint* might help improve quality, letting folks know just how important their work really is in HELPING someone's life might do even more. Knowing that someone really *cares* about your work is perhaps more important that simply knowing that someone *complains* about it.
So I left it all in (although I rearranged a few things so that the whole video presentation ended with the customers saying their most encouraging words). In a twist, my partner Bert was one of those interviewed customers. And shortly after that, he began telling me a story (I'm hoping he'll blog more about it, but here's my short version) about a software development job he had for about ten years. The company made extremely sophisticated AI-based broadcast scheduling software, that was initially sold to small radio stations and eventually made its way into large television stations and even cable channels like AMC and BET.
The story was that everyone--EVERYONE--in the company had to do regular rotations through tech support and customer training. Made no difference who you were. Managers. Algorithm gurus. Sales. Everybody had to spend time (and not just once at the beginning of their job) answering the damn support calls and teaching the customers how to use the software. Can you imagine? Can you picture what would happen if EVERYONE who worked on a software program had to spend time teaching customers to use it? If they had to experience the frustration not just during development, but AFTER it's deployed in the field?
Now, XP and other development models like "The Handcuff Technique" do make heavy use of customer input, often demanding that a customer be part of the development team. But what happens *after* the product is out in the world? How often are the developers involved and accountable to the customers *after* the product is deployed? And what would it be like if *everyone* in the company spoke with and--shocking--LOOKED at real customers on a regular basis?
But it can be done simply, quickly, and for virtually no budget. Borrow a video camera. There are no excuses these days--if you (or SOMEBODY there) has a machine with Mac OSX, you can get a cheap digital video camera and edit the video using the (free) iMovie software that comes with OSX. If you can't manage that, take still photos and a simple voice recorder and get them talking. It's crucial that developers (and everybody else on the team) hear the REAL voice of the customer (not just the printed, compiled, sanitized PAPER "voice of the customer" reports that many companies generate).
Then circulate the videos/pictures/voice recordings. Let your team know there are REAL humans back there. Let them know that thier work matters. Really matters. And no, it doesn't have to matter as in, "You're building the software that's going to save thousands of unwanted puppies..." It can be as simple as, "You just made this woman's life a tiny bit easier. And guess what, she's going to use that 10 extra minutes to check on her kids at the in-house company day care." Or maybe even, "You just made things a little more fun for this guy. He can now do something cooler and more interesting than he could before." Think about it. Think about the ways in which some of the simplest, most mundane-seeming products or services have had a butterfly effect on your world. And don't just do it once. Do it quarterly. Or monthly. Keep the customer's face in the employee's face.
Help your team find out how their work is changing lives, and it'll change the lives of your team. Even if it's just a tiny bit, the butterfly effect could be dramatic. It's so easy to think that our work just doesn't really matter in the real world. But it always does. Whether you're building a game, an eCommerce product, a training service, a book, a scheduling program, and even if you believe it's the most boring product or service in the world. If even a single human has to use it, you're having an effect. It really could change lives.
Or maybe I'm just caught up in the whole "It's a Wonderful Life" spirit of the season ; )
]]>