Behind every great man...

I don't normally think about book reviews as a subject for this space but Galileo can be considered an Honorary Codewright. So with that said, here is a review I wrote this past summer...

Over the weekend I finished reading Galileo's Daughter by Dava Sobel. It was a fantastic read. It's more of a biography of the great man but told really well. I was impressed with the historical research from political/military events around Europe to the intrigue of the Catholic church. Even minor things, like getting to hear about his family's financial troubles or the details of printing a book in those times brought enlightenment. I never knew that cloistered nuns in the 17th century had to deal with money to such an extent. There are several things that really come through. The man was as devoted a Catholic as you'd ever meet. The idea that he had gone against it brought him to his knees. In contrast to his faith, he also had a deep desire for the truth and this legendary collision between faith and science, centered upon this one brilliant and pious man, speaks volumes about human nature. What you will not forget though is his relationship with his exquisitely minded (his words) oldest daughter Virginia who took the appropriate name Maria Celeste when she took her vows. Even though his letters to her do not survive, we have a treasure trove of her letters to him that reveal as devoted a daughter as any father could ever want. That she reveres him and dotes on him is even more incredible considering it was all done from within the walls of the San Matteo convent. From the mundane news of her fellow nuns to the huge responsibilities of taking care of Galileo's estate and accounts while he was in Rome facing charges of heresy, she was always there for him as he was for her; ever his confidante, his guardian angel, his supporter, his devoted daughter. The author closes the story with such care and brings the relationship between the great man and his reverent daughter full circle in such a way that, like the motion of the stars he strove most of his life to reveal to the world, the soul of the reader will be forever moved.

This is the short form. I need to write a longer review, hopefully later this week.

Identity Crisis

I was reading through Ed Yourdon's "Decline and Fall of the American Programmer" the other day. In Chapter 5, section 5.8.6 page 127 to be precise, he is comparing the differences between practitioners of Structured Analysis (SA) and Object-Oriented Analysis / Design (OOA/D). In commenting on how OOA/D values reuse more than SA does Yourdon trots out the standard inheritance example of Vehicle (parent) / Automobile (child). It hit me that this example of inheritance is actually a very BAD example. However innocent this example may seem, it can sew a false sense of security in a programmer.

Summary
1) Inheritance is a complex topic
2) Using a simple example to introduce a complex topic is admirable
3) Using an incorrect example creates students who, among other possibilities, try to extend the example and become confused or have a false sense of their understanding of the subject.
4) Using a bad example in class materials is inexcusable for a teacher who claims they understand the subject and who care about what the students get out of the class.

I tried to explain my reasoning to Craig and here is how the discussion went.
Note: Link to the definitions used by the FAA to distinguish aircraft types.

---

Kelly
The things which we like to use to show inheritance are really capabilities of vehicles in general
I created a list of categories like so:

Craig
I'm still not sold on the idea that an automobile, train, boat, etc breakdown is a bad classification

Kelly
Vehicle; land, water, air; wheeled, hulled, tracked, winged, floats; motorized;
A car is wheeled and motorized for land
a boat is motorized and floats
If you try to put 'wheeled' in the hierarchy it gets strange when you want to declare a plane
It is motorized, has wings but can also have wheels.
You can't attach 'wheeled' to a pre-ordained location in the hierarchy
Knowing a vehcile has wheels does nothing to tell you where it belongs in the hierarchy.
An amphibious landing craft, an airliner, and a car all have wheels and they have motors.
All those things are actually attributes of some category at a higher level

A car is shorthand for a collection of attributes: piloted, wheeled, motorized, land vehicle

If you use those terms to define your hierarchy, you get problems when you introduce vehicles with different combinations of capabilities.
A Barge is unpiloted, floats, unmotorized, but is still a boat
A hot-air balloon is piloted but has no wheels or motor but is still an aircraft

Craig
hmmmm. I need to ponder more

Kelly
food for thought, at least?

Craig
yes. a mid afternoon snack
I think your approach is a valid approach to deconstructing the hierarchy, but I don't think the use of "automobile, boat, etc" is wrong.

Kelly
using them as labels is fine
but it becomes hard to use them in a OOP hierarchy without being about to define exactly where they belong and the differences between them.
There are much better subject areas to use, like the animal kingdom
where you can easily say "All live-bearing animals are mammals"
Unless a teacher knows how to categorized vehicles as clearly, they should avoid using it as an example
I believe that the FAA defines a plane as a fixed-wing aircraft. Helicopters are aircraft but aren't fixed-wing while hot-air balloons are aircraft with no wings at all.
In other words, 'Plane' is an instance of a class of vehicle called 'fixed-wing aircraft'

Craig
While cars are four wheeled passenger automobiles and big rigs are eighteen wheeled cargo automobiles, perhaps

Kelly
I got that wrong.
A 737 is an instance of a class of vehicle called 'fixed-wing aircraft'
which we call, a plane.
you do have the right idea

Craig
So you're saying automobile is too generic of a word.

Kelly
A 'plane' is not a type

Craig
I can accept that

Kelly
right

it lulls the student into thinking they understand the is-a relationship
Using planes might be better because the FAA has to use precise definitions or else their regulations would make no sense.

Kelly
is my rant making more sense now?

Craig
yes
The FAA definitions as an example helped
It gave me something to compare against

Kelly
Yes, they define legal regulations for things like 'right of way' based upon the maneuverability of an aircraft.
rotary-winged craft gives way to a fixed-wing craft gives way to a hot air balloon

Craig
I kept thinking the actual classification of vehicles as certain types can't be wrong, but the fact that the general classifications we use in classroom examples as too generic is an insightful observation

Kelly
for the simple fact that the maneuverability goes down
Have you seen the email where an aircraft carrier is in radio communication with someone else
and the carrier is insisting that the other party get out of the way?
and it turns out that the other party was in a lighthouse.

Craig
ROFL

Kelly
Distinctions are important.
When we teach about inheritance we're smack in the territory where distinctions are critical.
When we use the 'vehicle/automobile' example we fail to enforce with lax distinctions

Where do you go from here, and where is here exactly?

Developers have a love / hate relationship with version control systems. A related post is this one on 'Scar Tissue'. On one hand they either don't do something you desperately need regardless or any pleading or begging. On the other hand they do something that 'conveniently' adds to your workload and refuses to have it any other way. However maddening a VCS can be, software development would be a nightmare without one. Most shops have a preferred tool which is a polite way of saying "Use it or else!" That being said, developers typically learn to use the preferred tool and leave the administration to someone else.

Installing a VCS for my personal work has been on my todo list for a while now but always got pushed onto the back-burner. In the past I've actually worked in a serious development shop that didn't have any versioning system for the first few years I was there. They didn't collaborate much or have the need for branching and since it was my first gig out of college it didn't have that "working without a net" feeling that it would these days. That shop did finally move to Sorcerer's Apprentice before it was bought by black-hole of software known as Borland. After that was PVCS which was expertly configured and taught me a great deal about the benefits of a rationally conceived and executed version control system. Using promotion groups in an orderly way to move code changes along a path from 'only-seen-by-me' to 'ready-for-final-testing' was an arrangement that I wouldn't see again. From there was Visual Source Safe which was serviceable, which means I wasn't the admin, but wasn't very robust. Then there was RCS/CVS which work better than nothing but still leave something to be desired. At this point I realized that the thing I was searching for was not to be found in a tool but in the common understanding of a group of developers who share a development environment and work together to get the most out of the VCS and make each others jobs easier. There is a lot to be said for sitting down as a development team and hashing out a commonly understood development model.


Where am I going with all this? The company for which I work has a policy of buy over build which was served them well for the last 10 years. They've kept their IT costs down while still getting applications deployed for their internal customers. The vendor was trying to write applications it could turn around and sell to other companies in the same market and my employers got a discount on the work; everyone was happy. This arrangement went south when the development partner decided to get out of the business of writing and selling software. They parted ways without rancor but now my company is left with application code for which they have no experience in managing. That's where I come in, to help them with managing software, to advise them when vendors try to close a sale with marketing smoke and mirrors, and to detect when those vendors could be hiding important details about their product or service.

So, I ask for the code and am given a large ZIP file, I kid you not. Evidently the off-shore group of the development shop used by the vendor uses Visual Source Safe locally but it isn't used by anyone here in my office. That led to another nightmare when I researched how code was deployed to production but I'll save that story for another time. I've used VSS before but since most of the code is Java and we're not using Visual Studio, it didn't make sense to use VSS. After poking around on the Internet, I found some really good reasons not to use VSS. Evidence about corrupted databases, well documented issues, and stories from the trenches made it easy to decide to use some other tool.

My first thought was to install Subversion so I downloaded it at home and started learning how to manage a repository. Someone at work mentions a new VCS called 'Git' which is fairly new on the scene, so when I checked it out (there I go again) and at first figured we didn't need the multiple author patch model, where a change has an author and a submitter which is useful for accepting patches through email. After more thought the realization came that the strength of the tools like PVCS or IBM's Rational Clearcase were that they understood branches even if you didn't use them all that much. Subversion doesn't have a great track record with branching. Since the budget was tight that means sticking to free products which came down to Subversion or Git. I'm leaning towards Git.

Off into the wild blue yonder I go. If anyone has stories and/or advice on setting up a VCS for the first time, I'm all ears.