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.

Pro T folding

The title of this post was meant to have you think about Protein folding, but actually refers to T shirt folding.  I thought it was worthwhile bringing it to your attention, (1) because it is very cool, (2) if you do it, it will save you time, (3) it is a very effective instructional video and  (4) it was posted on Pavel Curtis's blog and Pavel is a legend in software.  You can  read Pavel's  T shirt blog entry with ya link to the relevant video, here.  (If you have difficulty accessing it, send me mail.)

Here's a bio of Pavel I scarfed from this MIT website,

Dr. Pavel Curtis received his bachelor's degree from Antioch College in 1981 and his
master's and doctorate degrees from Cornell University in 1983 and 1990, respectively.
Since 1983, he has been a member of the research community at the Xerox Palo Alto
Research Center, where he has worked on aspects of the Smalltalk-80, Interlisp-D/Xerox
Lisp, and Cedar programming environments and other projects related to the design and
implementation of programming languages. He led the SchemeXerox project, which
explored large-scale software development in the Scheme programming
language.



Dr. Curtis is the founder and chief administrator of LambdaMOO, one of the most popular
recreational social virtual realities on the Internet. Since 1992, as co-leader of the Network
Places project, he has been working on bringing the benefits of network places to a broader
range of users and applications.

I will discuss some of the topics including MOOs in a later post.  Pavel is a legend in software and (good) hacking circles.  His work (along with others of course) with Interlisp, Cedar, Smalltalk and Scheme formed the basis for how we develop today.  He is a luminary of computer science well worth knowing.

Since my title alluded also to protein folding, a bit about that reference.  My personal iMac at home (melmac, a G5 2 gig beauty) when not dealing with me, happily runs protein folding, climate prediction and SETI.  BOINC, software from UC Berkeley manages these apps and it is a great experiment in GRID computing and a way to donate cycles to your favorite scientific research.

However, if you are not interested in delving into any of these topics, please at least view the  t-shirt folding video.  It is fascinating and, for the laundry folders, could give you more time to enjoy these last days of summer.  Later!

Slideways

The title is actually a takeoff on the recent movie Sideways.  I liked it because it was a decent movie, featured Saabs, has great scenery and inspired me to investigate pinot noir. 

Enough digression, what the title Slideways refers to is my tendency to provide a ton of viewgraphs for my classes.  I rarely go through the bulk of them in class, but I do feel providing a comprehensive set is important since it can provide a quick, topic based resource when work or research insists that you dive deeper into a topic.  They also are accessible, since I provide electronic copies during the semester and have them available at my homepage (except between semesters when I am doing site cleaning, but you can always email me and ask).

During the classes, students are not always convinced, as they have to wait for the slides to be printed and lug them to class or wade through them when studying for a test (then again they provide decent summaries of the readings, useful as a study aide).  However my main purpose was to provide a resource that lasts longer than the class.

What inspired this post was an email from yet another student who actually found that there was life for the slides past class. In his case it was investigating software metrics.  I use them for my work too and initially that is what motivated me to obsessively provide them for you and start the web page on the external internet so that they would be available to you.   I would appreciate feedback from anyone else who has found the slides, the site or the blog useful

So as this semester begins and you yawn as the printer churns out a seemingly endless stream of slides, know in some not to distant future it may save you time, so that you can spend time with your family, watch a movie, take a ride in the country with the top down, enjoy some pinot noir or your-choice-here.  Later!

Emotional Talk

I attended AAAI last month and was on vacation so that is my excuse for zero posts last month.  A few of my posts in August will discuss the conference.  This is the first of them and it is a discussion of Marvin Minsky's keynote address.

There were two main themes of his address one was a discussion of his upcoming book, The Emotion Machine, hence the title of this blog entry.  You can find the first eight chapters of the new book by going to his main web site.  He also recommends reading Push Singh's Ph.D. thesis which can be found on Push's web page here.  I will provide some commentary on both of these over the next few months, but wanted to provide you with the references immediately,

The second theme, related to the first was that AI needs to be refocused.  He said that recently AI has gotten Physics Envy, trying to find general methods, but yet most of the programmtic successses in AI, according to Minsky, have more to do with Moore's law (computers became more powerful and could search more) than with advances in AI.   The talk was great, for example, he declared that in AI and psychology Occam's razor is the wrong idea; you are describing a complex system and it is not simple!
To quote from chapter 1 of The Emotion Machine:

So this book will embark on the opposite quest: to find more complex ways to
depict mental events that seem simple at first!

As I said, more discussion on Minsky's ideas will be forthcoming as I read the book.  Just wanted to provide you with more possibilities  to read as you hopefully take to the beaches in August.  Check back, as the Fall term starts getting together I should be posting more frequently -- and catch up posting some of my student's blog entries.   Later!

Having an Impact

If you cannot ascertain from the name of this blog, I will tell you that in addition to computer science and psychology I am interested in space exploration, astronomy and climatology.   On July 4th NASA is attempting to crash part of a space probe into the comet Tempel 1, with the main craft recording the event.  If all goes well the craft will be placed on an extended mission with its next probable target the comet Boethin. It will take 3.5 years to get there.  So even if you read this after July 4th  2005, there is still more to explore with this probe.

A frequent contributor to this blog and former student, Greg Horvath works at JPL on this project and sent me this heads up a few days ago.  I wanted to share Greg's logbook entry with you.  The text was provided by Greg with some minor edits from me.  Actually there was more interesting stuff on testing in his entire email, but I will save that for another post.  Later!

So, on to the fun stuff:

- We release the impactor Saturday evening, 7/2, at 11pm PDT (2am 7/3, Sunday morning EDT).
- Assuming all goes well, the impactor will arrive at the comet at 10:52pm PDT on Sunday night (1:52am EDT Monday 7/4).

In addition to the instruments on-board the spacecraft, we will have a number of other on-orbit telescopes taking both visible and spectral images (Hubble, Chandra, Spitzer f/k/a SIRTF) as well as many ground observatories including Keck, Palomar, and the SMA.  There will be plenty of gooey data to check out if this goes off as planned.

Our mission website has a schedule of programming
http://deepimpact.jpl.nasa.gov
As of right now, the schedule is:
----------------------------------------------------
Deep Impact Press Encounter Events - Jul. 1 - 4
(All times PDT.)

    * Pre-impact briefing: July 1, 10 a.m.
    * Pre-impact update: July 3, 11 a.m.
    * NASA TV coverage: July 3, 8:30 p.m.
    * Expected time of impact: July 3, 10:52 p.m.
    * Post-impact briefing: July 4, 1 a.m.
    * Post-impact press conference: July 4, 11 a.m.

Also, there is some animation and a few videos over at http://jpl.nasa.gov.  Click on 'Night of the Comet', and it will launch a little flash player.  (In fact if you click the picture of the woman under the 'Videos' tab of the flash player, you can see me near the beginning of the clip being a big dork.)

As I've mentioned, we will be on NASA TV, which you can stream online at http://www.nasa.gov/multimedia/nasatv/  (see times above).  I'll be on-console for impact so if you tune in you may see me pointing to a blue screen and doing other amusing geeky stuff.

Other good sources of info are:
http://space.com
http://spaceflightnow.com
(This site usually has good real-time info updated during critical mission events).  Also, our mission webpage http://deepimpact.jpl.nasa.gov will be updated in near real time during encounter, including images as they come down.

Lastly if you're in the SoCal area, the Planetary Society will be holding an event with real-time data streaming in and running commentary.  More info here:
http://planetary.org/cometbash.html
It's in Glendora, and entry is $20.  There will be some guest speakers as well.

Once upon a time ...

It is easy to be cynical in this age of outsourcing, impossible schedules and managers who think the only valid motivational technique is fear.  It is hard to remember the sense of wonder of software and computers that initially lured us into this field.  In working on Research for another task I came across an article by Allen Newell, "Fairy Tales," AI Magazine, WInter 1992. Note that you have to find the article in the table of contents, the first click on the title provides the abstract and clicking on the title within the abstract provides the article. It is a short, 3 page article and I highly recommend it to give yourself a boost and get back to viewing the big picture of why you do what you do.

The article discusses computer science and the promise it provides.  Rather than summarize it, I urge you to read it.

A bit on Allen Newell.  Allen, along with Herb Simon, Marvin Minsky and John McCarthy are known as the Fathers of AI in the United States. He was a great guy and had a great sense of humor.   He also was very direct and got right to the point.   For my Human Computer Interaction courses I have a clip of him struggling with a photocopier.  His personalty shows through perfectly. He died over a decade ago but the ripples he started will continue for a long time.

To close this off I would like to quote the last sentence of his article:

Finally, I wish to express my feeling of childlike wonder that my time to be awake on this earth has placed me in the middle of this particular fairy story.

Later.

Tomtoolery

The title of this post is a takeoff on the word tomfoolery which means foolish or senseless behavior.  One of the discussion topics for my Software Engineering course concerned building and using your own tools.  One of the students in the discussion, Chris Slater, offered this insight:

I am fairly new to the industry, so I have not developed a set of tools that I carry around.  However, at my new job, I have begun to develop these tools.  The funny thing about this is I created these tools in hopes of standardizing the tool set for our new project; however, once the other developers got a hold of these tools they either: (a) threw them away, or (b) rewrote them to fit their personal preference.

I then asked the class:

Did you ever ask  why they tossed or modified the tools?  This is a common experience and it would be nice to understand the, "not invented by me syndrome."  Is it lack of documentation?  Lack of Support?

I do notice that the use of tools, and reuse in general, follows an inverse square law of distance between parties.  It is much more likely that I will use tools or code from someone in an office nearby.  The probability drops off quickly the greater the distance. 

The only time I saw this not happening was during the mid years of UNIX (1970s-80s) and that was a factor (I think) of excellent documentation, UNIX manual pages, and a strong culture.

I did not expect anyone to respond, but Chris did (this is a paraphrase, it was longer):

Now, I also did some asking around and from what I can tell the two most prevalent reasons why tools such as mine get rewritten are ego or poor documentation.  I have to tell you the latter is one of the bigger problems I see.

What do you think is the reason for not using others tools?  Is it my distance inverse square law of reuse?  Is it poor documentation?  Is it ego?  Is it another reason?  I would appreciate your insight into this tomtoolery.

Thanks and later!

Sourcery

Julia Ryan has suggested another blog entry on source code management.  What tools do you use to manage source code and are these tools capable of providing statistics on the evolution of the source code?  If so, what sort of metrics do you typically collect and at what level (class, module, file or project)?  For example can your tool report the changed lines of source code and, if it can do you use that metric?  What other metrics do you use?

Generally we use CVS, but I am converting to Subversion, which seems a bit more straightforward.  To quote from the Subversion web site:

Subversion is meant to be a better CVS, so it has most of CVS's features.  Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.

I will report later this summer on my opinions of Subversion.  Of course if any of you have used these tools (or others), I would appreciate your comments.  Later.

Program for Programming?

This summer part of my resolution is to clear my back log of blog posting from students (and add some of my own).  This blog is from Curtis Eckhardt from my Fall Software Engineering course at Stevens.  He poses the question: how does someone get started/accomplished in programming?  Is it solely through classes?   

What is or was your program for programming?   My program began as an undergraduate.  I had taken several classes that introduced programming concepts as part of their class (statistics and laboratory instrumentation) but I had not taken a programming course.  During the month break between the Fall and Spring semesters (1972-1973) I spent the holidays at home and then returned to school for 2+ weeks.  A professor (Don Walter) had given me a key to a room that contained a PDP-8 minicomputer that was used by the psychology lab for presenting and controlling experiments.   After those 2+ weeks I had a thorough grounding in assembler language and continued learning throughout the Spring semester.  That was my introduction to programming, which continued when I entered the graduate program at the University of Pittsburgh in Fall of 1973 and was introduced to the  PDP 15 installation at the Learning Research and Development Center. 

I am sure there are more current ways to learn programming.  What is your experience?  Do you  try to learn at least one new programming language a year?  I do and I encourage my students to do the same.  On to Curtis's post - later!

Here’s a question that jumped into my mind the last class:

How do you jump into programming?

Honestly? I suppose you could start by buying a few programming books… but that seems a bit overwhelming. I mean there are many areas in programming. Hell, even picking an appropriate programming language can be a pain. Of course, other questions have to be raised before this conversation can go any further. So I’ll use what I know best and setup a scenario based on me:

You’re in college and would like to learn how to program because it appeals to your sensibilities. You’ve taken two programming classes and found that it’s fairly easy to pick up on. You also have in your head all the possibilities that knowing how to program can provide, but don’t know where to start. Being that you’re a mechanical engineer already approaching your junior year, you deem it unwise to switch over to programming engineering. So what do you do?

What I did personally was join a small organization called Windows Interest Group (WIG). The reasoning was simply, “surround myself with people that know how to program and want to program and it’ll rub off on me.” WIG was for a small group of people to get together and learn how to program. The only problem was the fact that the organization was brand new! I mean I was basically one of five people that was interested enough to return consistently. I didn’t learn how to program better, but gained a few more friends.

<Afterthought 12-14-04>
WIG was actually a Microsoft sponsored program. So a lot of the meetings were PowerPoint presentations of .NET and how it’s the “wave of the future” for programming. Promoting .NET was just a ruse to get money out of Microsoft. Even though the focus had to be on .NET technology, learning how to program was still the overall goal. That was fine and dandy, but what I was looking for was to get a group of people to work on a cool programming project. Our group tried twice… since we were all too busy with school and work, nothing was accomplished. Plus, there were only 2 people in the group that could have been lead since everyone else were essentially noobs at programming. Anyway, WIG is still active. In fact, visit the (now outdated) website: http://www.asu.edu/clubs/wig/index.html
</Afterthought 12-14-04>

Without a little direction it’s easy to get overwhelmed and lost in the sea of books and knowledge that’s out there. Where do you start and why? Are taking programming classes the only way to gain guidance? Since time is limited, how does one avoid wasting time?

What's up? Doc!

The most recent lecture in my Human Computer Interaction course included a section on Documentation.   A basis for either electronic or paper documentation is a clean, crisp writing style.  Almost anyone can achieve such a style with practice and some help.  A major resource for effective writing is Strunk and White's,  The Element's of Style.  This short book is a must in your library.  I've had a copy for years. (The cover price on mine reads $1.95, so it has been a while.)   There is a new (fourth) edition of the book with an additional author (Roger Angell) and it sales for $7.95 at Amazon. (Amazon's Better Together deal pairs William Zinsser's book, On Writing Well, which is another classic.)

Best of all, if you would like to browse before you buy, there is an on-line version of Strunk and White that is available here.  In addition, samples from Zinsser's book are available here.  If you like either or both, I would get them for your bookshelf.  Using them, while not turning you into a novelist, will definitely improve the clarity, crispness and readability of your prose.   Highly recommended.   Later!

 

 

Commanding Topic

This week in my Human Computer Interaction class I am discussing the various interfaces:  Direct Manipulation, Menu/Form Completion/Buttons and Command Line.  I have to admit that many times I favor the command line interface above all else for many tasks.  Yes, I still use Emacs and vi and feel a bit frustrated at times over the inability to bend the menu  items of Word or Power Point to my needs.  I also have not found a direct manipulation interface the I totally like although Apple's OS X  comes close.  I really dislike X Windows, always have, even when I had a SPARC I pizza box with purple feet.

(You have to be old to understand that one.  Basically the first Sun SPARC had a large pizza box form factor and its feet, rubber squares to elevate for heating and protect the desk top, were purple.  The day they unvieled the Sparc I, which was revolutionary, all the engineers were wearing purple speakers and it wasn't until the unveiling that folks in the audience got the subtle hint.  Whew, what a digression.)

All of this reminded me of Neal Stephenson's essay, turned into book, In the Beginning was the Command Line.  Although he referred to folks using command lines as Moorlocks, a not so kind reference from H. G. Wells, Time Machine (read the book, the movie was horrible), it is a great essay/book.  Even better, a version of the essay is on line with updated comments by a fan.  You can find it here.  Although I appreciate that the fan, Garret Birkel, made it available, I would focus on the original Stephenson text and  then return and read Garret's comments.

I hope you enjoy it!  Later.

Is there an architect in the house?

Julia Ryan, from my Stevens Architecture and Design class, wants to know how many software system projects use architects. Do you use them in your company?  Does it matter if it is a new or existing project?  Exert some care in your answer, since there arre many companies that provide the title of architect, but use it to mean a variety of tasks.  An architect for the purposes of this discussions matches Fred Brooks notion, that there is a single architect for a project that defines and fosters the conceptual integrity of the product.  Follow the link to get more information on what Brooks means.  We would appreciate your comments.  My development groups, regardless of size use an architect.  Later!

Julia Ryan's post:

Architecture is a fuzzy subject for me.  I think that the fuzziness stems from the fact that I have not been exposed to architecture at work.  I work on large software programs so I am surprised that I haven't seen it.  I wonder if it is because I work on legacy systems?  By legacy I mean, the code was originally developed years ago, and we are currently working on software upgrades (adding/removing functionality, code improvements, etc).  Or is it because Architecture is not yet widely practiced?  I'm curious to see if other organizations employ architects and architecture development on their programs and if they do, to what extent?

NKS Talk Wolfram

Attached is an email I received from Wolfram Science advertising talks by Wolfram in the metro area.  If you are interested in this controversial figure it would be a good opportunity.  In an earlier posting I mentioned that you can access the entire text of his book, A New Kind of Science, online.  You can access it here.  If anyone does attend his lecture, please post your impressions as a comment to this page.

I am hopefully going to be posting more actively again.  Later!

We thought you would like to know that Stephen Wolfram will
shortly be giving public lectures in your area.

Tuesday, February 15, 2005, 6:30 p.m.
University of Pennsylvania School of Design
Philadelphia, PA
http://www.design.upenn.edu/new/about/eventsdetail.php?eid=158
Room B1 Meyerson Hall

Wednesday, February 16, 2005, 6:00 p.m.
Princeton University School of Architecture
Princeton, NJ
Jean Labatut Memorial Lecture
http://www.princeton.edu/~soa/
McCosh Hall, Room 50

Thursday, February 17, 2005, 6:00 p.m.
Pratt Institute School of Architecture
Brooklyn, NY
Spring Lecture Series
http://www.pratt.edu/arch/
Higgins Hall

Friday, February 18, 2005, 1:00 p.m.
Rutgers University / DIMACS
Piscataway, NJ
http://dimacs.rutgers.edu/Events/2005/abstracts/wolfram.html
Busch Campus Center
http://maps.rutgers.edu/building.aspx?44

Dr. Wolfram will discuss new ideas and discoveries from his book
A NEW KIND OF SCIENCE (http://www.wolframscience.com), and their
implications for science, technology, mathematics and the arts.

The lectures are free and open to the public, though space may be
limited.