Revenge of the Managers

Yes it had to happen, albeit a bit late.  Twenty plus years after the Revenge of the Nerds, the managers have struck back!  They have established a new conference, Waterfall 2006.  However if you read carefully (or not so carefully) you will find it is a spoof on the waterfall model and that it actually is on agile methods.  Actually if you notice that the location is Niagara Falls and the date is April 1, 2006 you should question its reality.  (It is worth clicking on the Register now button.)

A bit of humor after a rough, cold week in January to begin your weekend.  Thanks to Diggdot for pointing to the post in del.icio.us.   Both are sites worth visiting frequently (I do) -- actually Diggdot provides summaries of a few sites including del.icio.us and slashdot.

Next week I will begin to work on my backlog of student postings.  Later!

About You

I have been asked by folks several times to provide recommendations on introductions to cognitive psychology.  Two popular books are: Cognitive Psychology by Solso, et. al. (isbn 0205410308) and Cognitive Psychology by Sternberg (isbn 0155085352).  The observant reader will note that cognitive psychologists are very creative in their choice of titles!  You also can obtain a free copy of William James, Principles of Psychology here.  Although it was written in 1890, it is still a great read on ourselves.  In fact if you are really into psychology, York University in Canada offers an archive of free classic books and papers here.  Highly recommended, especially if you would like to read a bit about some of the topics such as Gestalt Psychology that I briefly cover in class.

There also is a great online (shareware if you find it useful) book on task centered user interface design by Clayton Lewis and John Reiman.  You can download a copy of it here.   It is a very practitioner oriented book and highly recommended.  I knew Clayton when he worked as a user interface specialist at IBM Yorktown Heights (aka T.J. Watson Research Center) with John Gould. You can access a paper they wrote on designing for usability here. Clayton then moved to academia and is at the University of Colorado.

I will be adding more resources on psychology and human centered design in the months ahead.  Later!

A Key Model

I am currently teaching a course at Penn on Human Computer Interaction which stress an applied appraoch and only briefly mentions the academic underpinnings of the field.  A classic book that provides an insight into basic principles in HCI is Card, Moran and Newell's The Psychology of Human Computer Interaction.  It is a bit dated and may be difficult to get but it is well worth the effort to  find it at amazon, a used book site (I use alibris) or from a library.

One of the classic topcs in the book is a model of keystrokes that assesses the efficiency of a user interface.  You can get a Windows only calculator for this model here, just select KLM calculator. The SYNTAGM site also has other useful resources for HCI including card sorting and mailing lists, well worth exploring!

As the year progresses I will provide other resources for HCI and will mirror them on my website.  Later!

Real Architecture

Happy New Year! 

In every class that I teach (and now on my website), I always refer to Vitruvius and his 3 principles of design:  utility, durability and charm.  As is frequently the case the wikipedia has an excellent write-up on Vitruvius.  The page also leads to the original text of his book, On Architecture,  which can be found here.  In this translation, the fabled quote can be found n Book 1, Chapter 3, Section 2, "
All these should possess strength, utility, and beauty."

I have not finished reading it, but what I have read is truly fascinating, timely and also corroborates with the depiction of the Roman Empire  in the HBO series Rome, which I highly recommend.  I will post additional entries on this book in the next month.

Since 2005 was a busy year for me, I was not the best blogger and have lots of topics and student submissions in the queue.  I resolve in 2006 to be a much more active blogger, averaging at least one per week.  We will see at the end of the year how well I do!  It is always great to provide estimations and track it with reality.

Later!

Resource sources

Charles "Chuck"  Lutz presents a host of great resources on the web in this discussion group entry.  In particular he provides a reference to a Parnas paper and that is fantastic.  As you recall, I encourage any aspiring software engineer to get the Parnas' book of collected papers, Software fundamentals: Collected papers by David L. Parnas, D.M. Hoffman and D.M. Weiss(Eds.), Addison Wesley, 2001, ISBN: 0-201-70369-6.  Especially since the gift giving season is upon us, you might give yourself this book.  It will serve you well.  Highly recommended.

Mary Shaw's paper that Chuck refers to in van Vliet is "Some patterns for software architectures."  Mary Shaw and David Garlan also wrote a book on software architecture, Software architecture: Perspectives on an emerging discipline, Prentice Hall, 1996, ISBN:0-13-182957-2.  One of the few rigorous books on software architectures.

Attached is Chuck's log, entry, thanks Chuck.  Later!

I've got a bunch of stuff to share that I've accumulated over the years which I believe 
has relevance to this course. I'll send them along as time permits (I've already got a 
backlog...!)

FYI: Mary Shaw's paper that van Vliet refers to on p. 273 can be found here.

Parnas' paper "On the Criteria to be Used in Decomposing Systems into Modules" is an 
absolute classic of software engineering. It pours a lot of timeless wisdom into just six 
pages. A web search yields many sources (I would not be surprised if it is in the top ten 
of most referenced papers). Here is the first that Yahoo yielded me.

A few weeks ago Prof. Vesonder mentioned in his notes a review technique of posting 
information on a wall. This is a very interesting area to explore, especially in trying to 
solve the problem of establishing a common vocabulary and understanding - to "get 
everyone on the same page" so-to-speak.

Here are two sources I think you might find interesting:

I'm an "information design" nerd and enjoy following the work of people in the ID and 
information architecture fields (IA). I've always enjoyed the work of Marc Rettig. Here is 
one take on the "wall" process as applied to product design.


For a more formal take on the "wall" process, including aspects that computer scientists 
can relate to, I recommend David Straker's excellent book on getting maximum 
collectively derived information using quite cheap materials.


In the future we will have wall-sized displays and software support that maximizes this 
resource. I expect such techniques will become increasingly popular as the cost of 
making changes decreases in these models as a result of this support.

What's up? Doc! (redux)

The logbook entry from Ricardo Macarron  captures the need for  better documentation and a common language between software developers and their users.  He also lists some consequences of a lack of understanding of the software by the users and the tasks by the software developers.   There is a growing movement in the software development/user community to reach to a common language, a common understanding, usable software and readable and succinct documentation.  Part of that movement is captured well by Eric Evans' book, Domain Driven Design: Tackling complexity in the heart of software, 2004, Addison Wesley, ISBN:0-31-12521-5.

Domain Driven Design also has its own website and you can find it here.   Some of the discussion is certainly controversial, especially Evans' view on architecture, but it addresses important concepts that should help alleviate or at least moderate the problems dealing with software Ricardo describes in the log.  Later!

Ricardo's log:

Back to Software engineering. As an end user and chair of a couple of scientific fora within <my company  and both>resulting in requests for software tools, learning about software engineering is providing an opportunity to reflect on past experience. While designing a new software tool, users know that work processes are evolving and thus demand flexibility. Users always get reassurance from software developers that the new tool will allow for easy adaptation to new processes, but we have rarely to never got this at the end. Why this is so difficult? One problem is lack of common language among both communities (users and software engineers): “customers don’t know what they want” is a catch phrase (or hedging exercise?) used time an again by IT experts. Let’s crack this nut: could it be that the developers and the customers don’t interact enough in the planning phase as to get to understand each others desires and constraints? Prototyping before final specs looks like a win-win solution.
Requirements change because people don’t think as the program (logical steps) and the program doesn’t react to unusual situations as people (flexibility once again, fuzziness, exception handling…). For instance, I often encounter employees in retail struggling to use a program to answer a question or even to input an order without some lamentation or the worst “cannot do it, the program doesn’t allow it”. These “unusual’ situations, or in general unforeseeable combination of factors interplaying while using a software program, are hard to predict in length when programs are being designed. A better science on building up scenarios seems to be needed. It is like if designers/users were poor chess players only predicting one move at a time instead of chess masters seeing hundreds or thousands of options many moves ahead.

Mentalists need not apply

Satish Moorthy from Penn has recommended a great article by Karl Weigers, titled, "When telepathy won't do: Requirements engineering key practices."  You can access it here.  Although written specifically for folks using Object Oriented methodology, any project can benefit from it.  As an added bonus, Karl mentions some of the more popular requirements management tools.  Definitely worth a read.

Since Barry Boehm has remarked that as much as 40% of the requirements of the final product go unstated in the requirements specification, the more wisdom on this topic the better.  Thanks Satish.

Hopefully October will be a more active month for this blog than September, actually it already is since one is better than none!  I have a fairly large queue of potential entries and hope to make progress on the backlog this month so stay tuned.  Later.