A Growth Opportunity

One of the management euphemisms I have heard repeatedly over the years is  "growth opportunity," generally meaning a difficult, unpleasant or impossible assignment that is usually an offer you can't refuse.  William Lapenta from the spring Stevens Quantitative Software Engineering class, wrote this entry in his log and he provides valuable suggestions on how to deal with one class of growth opportunity, being handed responsibility without the necessary authority.  I hope you enjoy it and will offer additional suggestions on how you would deal with the situation.   Later!

Responsibility Without Authority

William Lapenta

One of the toughest types of situations professionals in any area of business can find themselves in is one where they are assigned responsibility for an issue without being given the appropriate authority to complete the task at hand.  This scenario is one that can be all too familiar to the developer or Software Engineer in charge of a complex and diverse project.  It seems that software projects lend themselves to this type of problem naturally. A developer, architect or SE must learn to tread carefully to successfully navigate through these waters.

What can often happen is that you may be given the task of implementing a system or project that interfaces with several other systems not under your domain of authority.  Learning how to deal with one’s peers can be as or more important than knowing how to deal with sub-ordinates or superiors.  When the line of command is not clear I have found that the best approach can be one of using more carrots than sticks.  The best solution to a problem, where you are not getting the co-operation you believe you need from a peer, is to somehow convince that person to assist you voluntarily.  Raising the issue to a higher level of authority should be your last line of attack, even if you believe you are one hundred percent in the right. 

Some methods that you might use in cases like this are:   Appeal to your antagonist’s sense of self worth.  When soliciting a peer’s assistance, tell them how important their piece of the project is and that you understand how difficult a task you are requesting of them.  By letting them have an elevated sense of self-worth, they may just complete the task out of pride.  Give them as much positive feed back as you can for any part of the task they have already undertaken.  Let them know how grateful you will be if they can assist you and that you would repay them in kind if the need arose.  Be willing to work around their schedule. If you are at a bottleneck due to this type of situation, it is better to have to put in the extra effort resolving the problem than having to explain your failure to your superiors.

If all else fails you may need to delegate the issue upward.  By this I mean, that there sometimes comes a point when you may need to finally raise the issue to a higher level.  This step should be taken very carefully and only as a last resort.  Once a bridge is burned, it can be very difficult or impossible to rebuild.  Remember, you will most likely have to work and deal with the person you are confronting currently again in the future.  It is almost always more beneficial to bite the bullet, swallow some pride and put in the extra effort to resolve a situation amicably (at least from your foil's perspective) than to come away with a successfully resolution for your current project while leaving hard feelings and an environment of ill will with your peers behind.

The Long Haul

Larry Bernstein once counseled me that one of the worst situations is to produce a product that is slightly successful always tottering on the edge of profitability and disdain from users while requiring unappreciated heroic support from maintainers. Maxim Dzoba in his log entry for my Software Architecture and Design class at Stevens, furthers the discussion on how success should be measured. He references a post from a website which should be in your bookmarks/favorites list. It is a thought provoking entry about how and when to measure success. Later!

MAXIM DZOBA'S POST:

Learning from your mistakes.

Many programmers read worsethanfailure.com (formerly thedailywtf.com). It’s a humorous blog which pokes fun at poorly written code, poorly designed applications, and ignorant programmers or management. One time the author posted a big entry that was unlike the usual humorous posts. In it, the author took on an interesting point of view about what it means for a software project to be successful or failed. He states that the common standards for a project to be considered successful are too low. Usually, as soon as a project goes live and money is paid, it is written off as a success and its authors move on to new projects. But, in reality, the product they developed might be, and often is, difficult to use, hard to maintain, doesn’t do its job well, or contains serious design flaws. It may even limp through its lifecycle being a tremendous sink of resources. The project, in fact, may be a complete failure. The author’s main point is that the only way to judge that a project is successful, is to follow it to the end of its lifecycle. But since people consider a project to be a success at its completion, they don’t go back to analyze what mistakes were made, which leads to a more serious problem: they don’t learn from their mistakes!

I was startled to realize that ours is the only industry where a completion of a project is equivalent to being successful. A building that crumbles after a few years or a film that no one would watch are deemed failures and this makes people go back to analyze their mistakes and learn from them. In software, however, it’s likely that people do not understand the mistakes they made and, worst of all, take their bad practices on to their next projects.

Beware of the Raptor

The Raptor F-22 that is. Raptors were the hit nemesis of the Jurassic Park movies (warning Flash splash page), but evidently Raptors can be dangerous to pilots too! According to reports, when the new Lockheed F-22 Raptor crossed the International date line communication, fuel and navigation subsystems were rendered useless despite repeated reboots! Business Week adds an additional report.

It may be quite possible that you heard this but I wanted to record this for future classes and track the post mortem afterwards. If you found other sources or additional information, please add them to the comments, thanks. Later!

Simple isn't simple

This post is about John Maeda's book, The Laws of Simplicity. I just finished reading it and was simply impressed. If you read the reviews on amazon, they are mixed. I have a simpler take, read it and judge for yourself. It is a bit over $10 and 100 pages. At most it will take you the equivalent of 3 episodes of 24 to read and you will learn so much more.

I liked it a lot, will require it in many of my courses (HCI and Software Architecture and Design) and willl have several future posts on it. I have espoused simplicity and know simple isn't simple, but Maeda helps us in its pursuit. Software folks and engineers need more grounding (fore and back) in design concepts and this is a simple, gentle introduction. It is well written.

It seems appropriate to make this first post simple. For more information, Maeda has a web site. Later!

Gift Suggestions for Valentine's Day and Beyond

Although this is written a few days before Valentine's Day, this post can be referred to for any gift -giving event to provide gift suggestions for significant others or family or perhaps even yourself!  Of course I think the best expression that someone cares about you is not chocolates of Vermont Teddy Bears or flowers but rather books!  In particular books on computer science, human computer interaction, science fiction or history.  So here, in no particular order of preference, are gift suggestions.

My new favorite for software architecture in fact, besides Shaw and Garlan, the only one I would recommend is Rozanski, N. & Woods, E., Software Systems Architecture, Addison-Wesley, 2005, 0-321-11229-6.  I like it so much that it will be the first architecture book used in my software architecture and design class next time around.  Thanks Larry Bernstein for handing me a copy!

For those of you who like code and love C (very related), this book will have you appreciating it even more.  It stresses the joy of reading code for fun and education.  Spinellis, D. Code Reading, Addison Wesley, 2003, 0-201-79940-5.

(By the way the links are not necessarily the best price for these books, I just spread them around the various on line booksellers.)

These is never enough testing and sometimes the bureaucracy of the testing organizations defy common sense.   A book from Whittaker, encourages all of us to place more thought in testing and appreciate superb testers.  Whittaker, J.A. How to Break Software, Addison-Wesley, 2003, 0-201-79619-8.

As most of you who have recently taken my HCI course know, I am stressing distributed cognition and activity theory as the basis for HCI.  A great HCI primer on applying this theory to practical HCI, that just released a second edition is Sharp, H., Rogers, Y. & Preece, J. Interaction Design:  Beyond Human Computer Interaction, 2nd Edition, Wiley, 2006, 978-0-470-01866-8.

There are some books I run across that I just have to fit into a course.  This book, originated at MIT for a course on software engineering and internet applications, is a gem and it WILL be in some course I teach next year.  Andersson, E., Greenspun, P. & Grumet, A.  Software Engineering for Internet Application, MIT Press, 2006, 0-262-51191-6.

Finally for the science fiction fans in the audience three can't miss books from three superb authors.  In fact any book from these three are a superb read and I have read all of Gibson's books and most of Mieville and Stross (and intend to read the rest).  The first is from William Gibson, Neuromancer, the novel that started (or at least popularized it, there were precursors such as Philip K. Dick) the cyberpunk genre of science fiction and a superb read.  The second is from China Mieville, Perdido Street Station, a mix of science fiction and fantasy (this says a lot because I typically detest fantasy).   For really modern hard science fiction Charles Stross  and his novel Accelerando stands out in the pack. It is a mind opening (might I say from my generation, mind blowing read).   What makes them very special in the science fiction ranks is that they are all superb writers.

I hope this provides you with a great list that you can hand others or use yourself for gift giving to you on any special ordinary occassion.  I hopefully will be back soon with some  student blogs. Later!

 

 

IVR versus Person

A recurrent discussion in my HCI classes is relating numerous user experiences with horrid IVRs  (Interactive Voice Response) and sharing techniques for cutting through the menus to contact a real person. I always cringe when I hear the complaints, since I have managed folks creating IVRs and I appreciate all the work they do to try to make such systems accurate, navigable and palatable.  Unfortunately, in many instances, the lack of flexibility in the telephony interface makes this difficult  at best.  The goal of many users encountering IVR systems is getting to an actual person.   Admittedly that has generally been my goal too!

However late last week two encounters in one day convinced me that IVRs done right can actually avoid aggravation.  My first experience that day was with XM radio. <digression> XM radio is a fine product but lately I have found I was not using it -- part of it was that it was a portable version and with my portable GPS and my cell phone, there were just too many darn wires floating through the car.  My next car will have integrated GPS and  some brand of subscription radio but for now the cell phone and GPS are more important. </digression>  I wanted to cancel it.  So I cruised through the IVR response trees and was finally connected with a person.  The attendant asked for all the information  including my equipment's ID and my address and then asked how she could help.  I said I wanted to cancel the service, she asked why, I told her I did not use it. She said okay she would transfer me to the cancellation department.  After a short wait, another attendant answered, asked again for all the information, seemingly bit by bit (I did grumble), and then asked how she could help.  Frustrated beyond belief I said I thought this was the cancellation department and I wanted to cancel my service.   She said it is the cancellation department and you guessed it - she asked why I wanted to cancel. After a minute she returned and stated that the refund check will be mailed to me in 2 to 3 weeks.  Of course I had to ask her for the amount.  Needless to say this entire user experience was poorly done.   Lest you think it occurred because I was canceling, my other two experiences with XM Radio customer support were similarly bad and that was when I asked to renew my subscription, to give them money.

Several hours pass and I am home.  While cruising through channels, Kath found pillows on QVC that were a great price.  I said I would order them.  I dialed the 800 number from our home line and the IVR asked for our pin. (We were a repeat customer.)  Since pillows were on the screen at the time it asked it that is what we wanted to order.  I said yes, indicated color and size with two more menus and the IVR repeated the order (all canned, pleasant, non synthetic speech) and that was that.  It literally took less than 2 minutes!  In 5 minutes the order was confirmed on my email account.  (I never received a similar confirmation from XM.)

Compare the two experiences.  QVC was optimized to save me time and to insure that the order was accurate.  Since I dialed from my home phone ANI, Automatic Number Identification, suggested my potential identity and providing my pin confirmed it.  The IVR was linked to programming so it knew what was likely being ordered and had a crisp script to get the necessary information.  In contrast XM Radio designed their IVR so that it would accommodate their fragmented systems.  Information was not transferred from interaction with the IVR to attendant 1 and from interaction from attendant 1 to attendant 2.  It accommodated their needs, not their customer's needs.  Additionally there was no confirmation even though it would have been simple to launch an email and check for accuracy.

In my adventures last week with XM Radio and QVC, I feel a bit more enthusiastic that someday I will want to access the IVR instead of a fallible attendant and that the hard work and design of HCI specialists and IVR developers will pay off.  At least in the QVC instance, the user experience was superb.  Note that the QVC instance made use of one of my pet HCI principles, the best interface is the one that has been eliminated through automation.

Sorry for such a long post!  I hope to accelerate through my back log over the next few months and hope you all are enjoying the holiday break and wish you all the best in 2007!  Later!

First One Web Day Tomorrow!

I have already provided an entry on One Web Day and for those of you that missed it please check back a few posts.  The first One Web Day is tomorrow, September 22nd, and I encourage folks to check on the One Web Day Site for activities in their area.  For folks in the New York City area, the festivities are at Battery Park in NYC. 

Some information on the NYC event:

Download sample_1.pdf

Download the_battery__map_of_the_battery_with_stage_and_truck.pdf

If there is no event in your area, consider starting one next year.   Contact me if you need suggestions.  We hope to enlarge the role of Universities next year.

The web is about community and this is one day out of the year when we recognize, celebrate and work to enhance and broaden that community.  The web is global and so are many of our problems.  If there is one thing I stress in all of my courses it is that communication is the key to successful products.  Communication also is an important factor globally for the same reasons, to understand each other and work  together to improve the process and the result!  Yes, I am showing my stripes as a child of the 60's!

So at the very least tomorrow, take a moment to reflect on how the web has affected you.  Later!