The Software Universe

Behave!

This is a great time of the year! I always loved September.  It is a bit cooler,  American and world football begin and school begins.  I will never forget the smell of new crayons in grade school, the gleaming halls and lockers in high school, the trees changing in South Bend and the never ending new challenges in Pittsburgh as first year courses led to thesis, led to comprehensives and finally to dissertation.  Nowadays it means new students for the fall term and freshly corrected log books from the summer term.  This summer term resulted in some truly superb entries.  Here's the first from Joe Rafaniello on Behavior Driven Development, a new technique in agile methods that I currently do not cover in my courses.  I am still not a big fan of specification languages but many folks use and love them and any software engineer should definitely give them a try to see if it works for them.

A relatively new concept in the agile community is behavior driven development.  I have recently researched it for work and feel it is a great way for developers to deliver programs that exhibit all behaviors required to meet customer requirements and at the same time have tests that back up the code.
    In BDD, a developer writes the test or specification first just as in test driven development.  In contrast to TDD, BDD is written in a language that looks more like English and lowers the barriers to entry for customers or project managers interested in what the code does.  This can be very convenient when small teams develop directly with their clients input.  BDD in Ruby is done using RSPEC and looks like this:

# bowling_spec.rb
require 'bowling'

describe Bowling do
  before(:each) do
    @bowling = Bowling.new
  end

  it "should score 0 for gutter game" do
    20.times { @bowling.hit(0) }
    @bowling.score.should == 0
  end
end
(http://rspec.info/)

The idea is that the developer writes the specs before the code.  The spec is run and fails the test. The developer then writes the simplest code to satisfy the spec and now the spec passes. 
    The benefit of RSPEC type languages are that even someone with minimal programming experience can understand the basics of the specifications.  Whenever the business side and programming side can move closer to each other through communication, the better odds of delivering the product on time and as specified.

If you are interested in rspec, check out the site Joe listed here.  if you have time add a note on your opinion of specification languages in general or RSPEC in particular.  The title was a quote from Austin Powers.  I could not resist.  Later!

Vinge on the Future

One of my mantras in my HCI classes is that often the best interface is no interface - essentially automating it away by doing the task or making the decision in the software which may or may not require AI.  A New York Times article today explores Vernor Vinge's speculations on where this automation may end.  The article refers to Vinge's essay on, "The Coming Technological Singularity" and his new book RAINBOWS END.  Vinge speculates/extrapolates that by 2030 computers will become so juiced that a new intelligence will emerge that will surpass humans and then what do these new intelligences do about us - thus begins the Post Human world.  That "then" has been the fodder of many SciFi books and movies (e.g., the Matrix Trilogy).  It also has been discussed in books by folks such as Kurzweil's, THE SINGULARITY IS NEAR, which expands on Vinge's essay.  Exploring this train of thought does cause one to give a sideways glance at the block of silicon on your desk!

My own take on this, hardly novel, is that it has been so difficult to get software to do anything that it is a lot farther off than 2030, if ever. In fact most of what I teach is focused on trying to coax software to doing anything intelligent and at least approximate what we want. Of course the humans involved in the software enterprise, do not make it any easier!

Vinge's potential solution is to partner with the computer and become better together.  That is appealing since each entity has unique skills to bring to the table and this seamless interactivity between human and computer is something we strive for in HCI.  In fact HCI as partnership is something to explore, that may lead to new way s of viewing the user experience.  Hmmmm more on that later - and more on emergence.

By the way, Vinge is a great sci fi (and computer textbook) author.  I would highly recommend sampling his work.  I often refer to his story, "True Names"  in first nailing the issues on cyberspace and privacy - he is one of the most prescient of the current scifi writers.

I would appreciate your thoughts on this and I thank the NY Times science section for the article.  A nice thought generator for these dog days of August!    Later!

A new era of "help" messages

Often in my HCI classes I state that the best human computer interface is no interface, that you should automate the task completely if you can.  I just came across a pointer to a video from doggdot, a blog aggregator, that is worth posting and you can find it here.  It shows a robot correcting a human in a cooperative task.  Two points worth noting in the video: (1) the dialog design that results in a rather firm correction to the human and (2) the fact that the human had to adjust the platform so the robot could place the bolt on the wheel - there still is a long way to go before you will work on a daily basis with an obnoxious robot.  Gee the aibo is discontinued only to be replaced by obnoxious robots!

I think I have my nth wind and hope to increase the frequency of my posts going forward.  Later!

Simply Google

John Maeda of Laws of Simplicity fame has created an official theme for iGoogle.  iGoogle constructs a homepage for your browser much like yahoo provides.  It is an interesting theme of shapes and colors that change each time you access it.  Probably too much color for me but I am going to live with it for a while to see if it grows on me.  Thanks to Len Accardi of my University of Pennsylvania HCI class for calling my attention to this.

One suggestion on studying Maeda's Laws of Simplicity .  Although the web page is a great place for discussion and listing of the laws, you have to read the book with Maeda's commentary to get the full impact of his study of simplicity.  One particularly discouraging comment of a student in one of my classes was why not just list the laws rather than requiring the book.  One really has no chance of getting what Maeda's is trying to accomplish without reading his book and commentary regarding the laws.

His book will definitely make my Valentine's Day list of books to suggest to your significant other as potential Valentine's gifts for yourself.

Later!

RISD Business

I recently discovered that John Maeda, author of The Laws of Simplicity, will become RISD's president in June of 2008. RISD, Rhode Island School of Design, is a remarkable place. RISD's mission says it all:

RISD fulfills its contemporary mission by providing the highest quality instruction in the visual arts, design, architecture and art education to prepare its students and the broader community to be creative and responsive to the needs of a global society.

IMHO both made a great choice and I will keep you posted on their joint growth. It should be simply amazing.

Later and Happy New Year!

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.