OLPC

It is fitting that my 100th post on this blog be about One Laptop Per Child. I have discussed OLPC in many of my classes, both as an intriquing concept and an example of focused design and Human Computer Interaction principles. You can read much more about OLPC here.

All of this is great, but the real reason I ma posting on this yet again is to encourage you to buy an OLPC. Yes you can buy one in a special 1 for 2 deal! Yes I said a ! for 2 deal. For a very limited time you can buy one OLPC machine for the price of two. The second one will be given to a child in a third world country an dyou will get a $200 dollar tax deduction. I have already ordered and, with shipping, my total came to $423.95.

I encourage anyone who thinks this is a neat idea and can afford it to do the same. You can begin the process at this site. This special offer i sfor 15 days from November 12th to November 26th, 2007. Get a great piece of technology and give a child in the world a very special gift for the price of a stripped down Playstation 3.

When I get my OLPC I will post my impressions here and on my other blog.

If you do order one, I would appreciate adding a comment to this post. Thanks!

Later!

One Web Day - It is about us!

Tomorrow, September 22nd, is the Second Annual One Web Day. As the OWD site proclaims: "The Web is worth celebrating. OneWebDay is one day a year when we all - everyone around the physical globe - can celebrate the Web and what it means to us as individuals, organizations, and communities."

One Web Day was started by Susan Crawford, a person of boundless energy and commitment, to celebrate the web and its contribution to the world. Many web luminaries such as Tim Berners-Lee, the father of the web, have added their message about OWD and it can be found here.

I find the web particularly special to this blog, since my web classes have introduced me to many individuals that I know and continue to communicate and share ideas solely through the web. The web has indeed provided personal and professional growth for many of us and that alone would make it worth celebrating an dreflecting on how we can make it better.

For those of you in the New York Area, you can attend activities and parties listed here.

Join in the celebration of One Web Day and visit this site for planning the third OWD. My goal is to get many educational institutions involved. Please contact me if you would like to help. Later!

Bartlett's Err, Rajapakse's Familiar Quotations

Bartlett's Familiar Quotations is a great place to explore "sound bites" from great literature. I find them useful for lectures, papers and t to explore some interesting nooks and crannies of great literature by taking the quote and then "reading around it" to get the context. In fact John Bartlett had a great quote about his quotes, "I have gathered a posie of other men's flowers, and nothing but the thread that binds them is my own."

Several weeks ago (by way of doggdot, I think) I discovered Damath Rajapakse's collection of Software Engineering quotes and had a great time sampling the quotations. Dr. Rajapakse has done a great service for software engineering students and lecturers alike. It is a highly recommended site to visit and bookmark, especially for folks interested in software engineering. Enjoy it and thanks to Dr. Rajapakse for creating such an entertaining and useful compilation.

Later!

Architectural Attributes

Hard to believe I am still working my way through posting great log entries from folks in the Spring term. This log entry from Deborah Ford in my Software Architecture and Design Class at Stevens lists great attributes for a software architect. I like that she emphasizes domain knowledge, breadth of experience, communication skills and mutual respect (architect should respect designers and developers; designers and developers and designers should respect the architect). In many ways that is a great formula for any leadership role but it is especially the case for the architect. I would like to thank Deborah for letting me share these with you. The key excerpt from Deborah's log entry:

Out of this (my experience) I’ve concluded that there are certain keys to success for architecture teams:

1. This isn’t necessarily a job for the most creative designer or best technician. It is more important to get someone who understands the big picture and can bring differing views to consensus or make a judgment when the situation calls for it.

2. Don’t farm out architecture roles to outside contractors – you are investing your knowledge capital in people who don’t have such a compelling reason to stay and can be at the whim of budgetary fluctuations. You are also giving lots of domain knowledge that your competitors may be able to take advantage of further down the line.

3. Team members should have a wide exposure and not be too wed to any particular technology or internal organization. I am wary of people who have spent their entire working career in a single organization.

4. They must be people who have the respect of the teams that they work with.

5. They must have a good grasp of the business domain.

6. They must not be seen as too allied with any single development organization

Hopefully, I will increase my volume of posts in the next few weeks since I have some backlog and a fresh stack of 30 logbooks to read from my summer classes! Later!

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!