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!

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!

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.

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.

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!

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.

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!

 

 

Mind the Gap!

Mind the Gap is an enigmatic phrase in the London Underground ostensibly referring to the space between the platform and the train and cautioning travelers to be aware of it.  This post is contributed by Lee Moss who is in the Executive Master's in Technology Management program at the University of Pennsylvania.   It discusses the technique of Earned Value Management  which, among other things tracks the gaps between Budgeted Cost of Work Scheduled, Actual Cost of Work Scheduled and Budgeted Cost of Work Performed. 

Everybody talks about how hard it is to estimate the cost and schedule of a software system project, but nobody wants to do anything about it.  That's what I got from the reading this week, so I went off on my own to see if some of the Program Management Best Practices (Boeing and otherwise) could be applied.  The first best practice that I looked at was Earned Value Management.

The first place I went on the web was a Google search for "software engineering earned value management." I found a number of useful links.

http://www.niwotridge.com/Resources/DomainLinks/EarnedValue.htm is a wealth of links.

http://www.stsc.hill.af.mil/crosstalk/1998/07/index.html is an excellent paper by Quentin Fleming & Joel Koppelman titled "Earned Value Project Management: A Powerful Tool for Software Projects." that provides very good insight to the EVMS novice, particularly on how EVM can be applied to a software project.  Editor's:  note:  I added the title of the article to the text and I also recommend the journal Crosstalk, from the US Department of Defense.  Subscription to it is free.  Check out the link.

http://www.stsc.hill.af.mil/crosstalk/2000/12/lipke.html appears to be another interesting article where statistical process controls were implemented in a SW project.  I didn't read this article in any great detail, but I have the link to return to if I need this in my tool kit someday. 

http://www.stsc.hill.af.mil/crosstalk/1999/03/lipke.asp talks about applying Management Reserve to SW projects- something every PM should be interested in.  In this article, they say "A nightmare for software project managers is "extras" thrown at them by the customer. Of course, revised requirements are supposed to be renegotiated and reflected by a revised project baseline that includes a new completion date and changed cost. However, many times the "requirements creep" seems so trivial that project managers forego the perfect practice and merely adjust their funding reserve to account for the change. For many situations, the effort required to re-baseline the project and negotiate the change is far greater than the amount of reserve lost. As an internal practice, we
advise customers that changes are being accrued and that we reserve the right to negotiate them once it is apparent the effort to do so is worthwhile; however, until payment occurs for revised requirements, the reduction in funding reserve will be reflected in decreased TFA and thus
a lower cost ratio."  I'm not sure that I am comfortable with this particular approach, because it seems to encourage incremental creep that goes unaccounted.

http://www.stsc.hill.af.mil/crosstalk/2000/06/lipke.html is more on statistical process control and software engineering.

In general, unlike the weather, it seems that a lot has been done relating SW projects to other program management tools.  I'll look at some of the other best practices another time.

We have met the enemy and they are us!

An article at msnbc.com states that software disasters are often people problems. The direct link to the MSNBC article can be found here. I was referred to the article by a posting in slashdot. Quoting the article:

Such disasters are often blamed on bad software, but the cause is rarely bad programming. As systems growm more complicated, failures instead have far less technical explanations: bad management, communication or training.

Although the article confuses what software is and is not (the SAP system is software, the application software added to it is not), the points it makes are still relevant. It refers to issues with requirements, stakeholder participation, operations, testing, end user training and inhomogeneity of technical understanding. Inhomogeneity of technical understanding is a multics term for a horrible project scenario which exists when managers do not understand software technology and developers do not understand the big picture, the context in which their software would run. Unfortunately this occurs all too frequently.

The article cites a National Institute of Standards and Technology study that software bugs cost $59.5 billon each year and a third of that can be attributed to inadequate testing. The pdf for the 300+ page report,"The Economic Impacts of Inadequate Infrastructure for Software Testing," can be downloaded here.

The title of this post was a quote from the comic strip, Pogo, penned by Walt Kelly which was an adaption of an Admiral Oliver Hazard Perry quote after a naval battle. You can find more information about the context of his quote here.

As always commenst are appreciated. Later!

Reliable Advice

Attached is a description of the new edition of John Musa's book, Software Reliabilitiy Engineering: More Reliable Software Faster and Cheaper. Thanks to Professor Bernstein for forwarding John's notice to me. Software reliability is one of the key "ilities" (along with usability, enhance-ability, ...) of interest when developing a software architecture. John's book has been a classic in this area and provides the reader with tons of practical advice and even free software to deal with software reliability issues.

Has anyone else used or read Musa's book? I would be interested in your comments. Later!

Musa's description of the book:

The new edition of "Software Reliability Engineering: More Reliable Software Faster and Cheaper," now available, focuses on making software practitioners more competitive without working longer. This is a necessity in a world of globalization and outsourcing where professionals want more time for their personal lives.

John D. Musa has written what is essentially a new book. It reflects the latest software reliability engineering (SRE) practice. Reorganized and enlarged 50% to 630 pages, the material was polished by thousands of practitioners in the author's classes at a wide variety of companies worldwide.

One of the book's new features is a series of workshops for applying each area that you learn to your project. The frequently asked questions (answered, of course) were doubled to more than 700. All the popular features of the previous edition have been updated and rewritten. These include the step-by-step process summary, the glossary, the background sections, and the exercises. The user manual for the software reliability estimation program CASRE, downloadable at no charge from the Internet, reflects the latest version. The list of published articles by SRE users of their experiences now numbers more than 65. Everything is exhaustively indexed to make the most detailed topic easily accessible to those using it as a deskside reference.

The book separates basic practice from special situations for faster learning. Musa presents the material in a casual, readable style, with mathematics placed in separate background sections. All this was done to make the book especially effective for self learning. It also furnishes everything you need to implement SRE in your organization, even discussing the most effective methods of how to persuade people to adopt the practice.

One of the first Print on Demand (POD) professional books, it is coupled with a web site where you can browse and order the book. The web site has a complete detailed Table of Contents and extensive samples from the book that simulate the bookstore browsing experience. POD uses the latest automated technology to custom print each order and ship it anywhere in the world. It is as fast as you can obtain a traditionally published professional book. The cost is similar. POD technology makes it economic to keep the book in print for as long as even a handful of people want it.

Musa is one of the founders of the field of software reliability engineering. He is an IEEE Fellow and is Engineer of the Year in 2004. Listed in Who's Who in America since 1990, Musa is a prolific researcher, international consultant and teacher, and experienced and practical software developer and manager. ACM Software Engineering Notes noted for the first edition, "The author's experience in reliability engineering is apparent and his expertise is infused in the text."

The book, published by AuthorHouse, comes in hard cover and paperback editions. It contains 630 pages, including prefaces and appendices.