What is a 'take-home' message? If you don't know, it's a term way-too-overused in the Fortune 500 (the largest corporations on the stock exchange). Call me cynical, but workers within the Fortune 500 organize way too many meetings (drove me crazy). The phenomenon makes great fodder (content) for jokes like the ones the Dilbert comic strip covers. Because everyone competed to get your attention at all the meetings you attended, a catch-phrase emerged in the 1980s. After you were lulled to sleep at a long, way-too-wordy meeting on some often-irrelevant corporate objective (irrelevant to you at least), the speaker would raise his or her voice (more volume) and declare, "The take-home message is ______". This was a way to wake up your audience and make sure they got the most important point of the meeting that had just taken place.
So, this primer provides you with the 'take-home' message(s) for the things I would like you to remember as you go forward in life. I drop the cynicism here (you should add your own for a healthy inner-dialog) and focus on the topics covered in the very quick exam you will take next Tuesday.
I fully expect everyone to answer all the questions correctly. There will be only ten questions. If you answer them all correctly, you should feel like you've learned something for sure by taking the course (unless, of course, you could have answered them before we ever even met). If you don't answer them all correctly, I would really like it if you understood why you got it wrong (so, please check the answers which I will post almost immediately after the exam). Then, spend a moment to get it right in your head for the long-term.
All the answers will be given to you in this primer. I *think* you should already know them based on the lecture material, but feel free to read on just in case.
The first take-home message I'm pretty sure you've etched into your memory. That message is the fact that the emergence of the Web has been the most important cause for the emergence of collaborative software development. Without the Web, collaborative software development was difficult. You could create a solution for a specific operating system (Windows, OS/2, Mac, etc.) and a specific networking software (Novell, Banyan Vines, etc.) but you would have very little chance of getting it working on any other environments.
There is no way ten years ago that we could have done the project 1 we did in class as quickly as we have (I should say 'great job' again to all of you) this quarter. Consider all the technologies you used:
Each of the above technologies works great for its intended purpose (but with lots of room for improvement and/or extension), but even more exciting (to me at least) is how they work so well together. Consider how none of the other four technologies (besides Internet Explorer of course) was initiated by Microsoft and yet they all work reasonably well within the Microsoft technology. Such interoperability was not really forseeable for those of use architecting networking solutions back in the mid-1980s. Why? Because the marketplace was dominated by IBM for business solutions and other providers in other arenas. IBM provided all your needs through a very strict host mainframe environment and software add-ons. Microsoft came along and seemed to replace the pieces one by one. Lots of PBS specials on the history. Enough said.
Anyway, for exam purposes, I hope you are very clear as to what each of the five technologies above is contributing to enabling Web-based collaborative tools. Think about the lessons learned by looking at the Habanero platform. With the Habanero platform, we can use Java solely to enable all the tasks covered by the five technologies above.
Think this through. By making a Hablet instead of an Applet, we can use Java to perform the visual layout that HTML usually provides. We can use a Java interface to any scripting language (perhaps I should have introduced the Python scripting language in class since many Java programmers are using the Java/Python interface to script within Java - but it works identically to how the Java/JavaScript interface works in Project 1) to allow for run-time scripts to affect the overall system behavior. We use Java to code a messaging layer that uses TCP/IP (Java does this extremely well) instead of needing the Web browser. And, we handle our own windowing events inside the Habanero client instead of letting a Web browser do it.
Imagine if a better messaging protocol comes along. We can replace TCP/IP with whatever new networking protocol provides better services (we mentioned UDP shortly early on in class -- UDP is the protocol on which 'streaming' technologies are built right now -- streaming audio, video, etc.). We just have to adjust the Java classes we use to point to the new protocol (which becomes VERY easy to do if you are given a half-decent example from which to imitate functionality).
Imagine if a better Web page language comes along (besides HTML). Well, perhaps you don't have to imagine as Flash and other 'page' authoring platforms are already plugged-into Web browsers like Internet Explorer. You can see that such 'new' authoring platforms just need the ability to do what HTML does when communicating with Java. Piece of cake should the platform developer want their platform to work with Java (and I would want it to if I were developing a platform).
You see the point? To be a good collaborative tool designer for the long haul, you just have to study the components from a design perspective. Don't worry which technology is the hot technology of the day. Just worry whether the new hot technology does what a collaborative tool needs it to do OR whether it has a clean interface to another technology that can provide that for you. What are the key components again (by now you should have them in your head cold)?
The second take-home message has to do with the paradigm (prevalent ideas) shift from procedural systems to object-oriented systems. I am perhaps a bit out of touch with how much you've been presented these ideas from other courses you've taken. I tried to get you to think biologically instead of along traditional computing thought (think of a computer science book written in 1970). Why do I suggest you think biologically? Becaue computer scientists have way under-delivered their software promises from the 1970s. As soon as their grand schemes reached a certain level of complexity, their coding styles couldn't manage the complexity they were creating.
Humanity has entered a new era of co-existance with nature. We've moved away from looking at nature as a spirit world (which inspired great awe to our ancestors) and instead look at it as a complex system (with the same awe-inspiring effect). In my opinion, looking at nature as a spirit world has been very respectful with a kinder footprint of our human presence left behind. Looking at nature as a complex system has lead to fantastic scientific discovery (the pace at which natural scientific discoveries picked up during our scientific awakening approached astronomic) to which the discoverers enjoyed a self-reported great quality of life. Because the rate of the accleration of scientific discovery has lessened substantially lately, we have turned to looking at controlling the nature we feel confident we understand (atomic nucleus, genetics, weather, ecosystems) to find that same quality of life as 'scientists' (this trend will get us into it-hurts-my-brain ethical questions going forward -- what if cloning and stem cells are just the tip of such an ethics iceberg?).
The benefit to computer scientists has been the realization that nature has to be what nature is to do what it does (sorry about the vagueness in that statement but I think you see what I am saying). The complexity is both created and managed by the natural process. So, the very powerful message unfolds as "don't fight nature, imitate it" (is nature an 'it' or should I be more respectful and refer to 'Her' in respect of your beliefs?). This is where the object-oriented paradigm came to the forefront.
You've seen Java a bit. By the time you are old and gray (assuming we haven't figured out the issue of biological aging by then), you might laugh at the simplicity by which Java attempted to mimic nature in computer systems design. Who knows what language will be driving the systems of tomorrow. I ask you to think back to the lessons you learned at this time and be able to forget about the specifics of the Java language per se. Think in terms of the VERY powerful concepts you learned: Inheritance, Interface, Containment (or call it Association/Aggregation using the vocabulary I briefly introduced you to last lecture), and Encapsulation (making things private but providing a public interface).
Let's review just so you can't possibly get them wrong on the exam Tuesday:
Inheritance is where one system component (a dog) inherits basic capabilities from another system component (living being) which is provided in terms of a class declaration (the .java files we used in Project 1). In a good system design of a dog, there would be other inheritance layers between living being and dog (the key is you have learned a bit about how to define those layers yourself when considering a design problem). Remember that Java uses the keyword extends to inherit from one class to another.
An Interface is a set of operations (or behaviors or methods) one system component must perform for the benefit of the whole system. A dog implements a circulation interface to carry blood from the lungs to the biological components that require oxygen. The dog depends on that circulation interface working properly for its survival.
Containment is when one component contains one or more other components within its system in order to perform the necessary functionality. The dog doesn't inherit two arms and two legs because a dog is not an arm or a leg (while a dog is a living being). The dog has two legs (contains two legs). A dog is so complex that to model it reasonably well you would probably find it contained thousands of other types of objects (remember that a class is just an object type).
Encapsulation provides a safe hiding of internal component workings in order that the component can't be tampered with by other components. To be a world-class designer, you have to do a great job of encapsulating attributes (variables) and methods (functions) inside of your classes. This encapsulation gives freedom to the class implementers (because they can change the algorithms on which operations are based without effecting other system components) and the class users (because they can rely on the fact that the component does only what it is expected to do). Think of encapsulation as the cell membrane's process of letting good chemical messages in and keeping bad chemical messages out. Our dog has a much better chance of survival if cancerous (carcinagenic) materials can't ever enter the cell.
With the studying you've done and the contemplation you've made, you are ready to look at more advanced concepts such as Polymorphism and Reflection. When you do, think in terms of the nature of things and apply the concept to the world around you before applying it to a system you are working on. Learn by using the senses you already so expertly use. Just be more aware of what you are sensing and how it is designed. Not an easy thing to do but a perspective I find very enjoyable from time to time.
The third, and last, take-home message is to consider the human component involved in your system design. Perhaps we should have spent more time discussing this in class but the technical lectures required a certain amount of time that left us short. Human beings are swayed heavily by human relationships and politics. Even the best collaborative tool will not overcome a political environment where the users aren't acting independently (they are swayed by some marketing catch-phrase, tax-structure, leader, threat, etc.). Then again, to be collaborative is to work together, right? So, that independence can't be overboard either. People have to believe in the benefits of collaboration. Think of yourself on a tightrope when you go to finally get a targeted group of people using your system.
You have to offer them some kind of informational freedom that they don't have today as things sit. You have to offer them some efficiencies or conveniences to manage the information better than they do today. But, you have to pursuade them to share information as much as they absorb it. Otherwise, your chances of having a success story are slim. My recommendation is never accept an offer to work on a collaborative tool project that has to be up and running by a certain date not so far in the future. That usually implies that people will be using it (and thriving with it) by then. Go ahead and commit to the technology being available at a certain date, but be sure to negotiate the fact that the usability is not completely in your hands. Make it a two way understanding. You will deliver the technology but they will be responsible for getting people to use it correctly and often.
Sadly, when it comes to human behavior, I have yet to be able to predict which systems will be successful and which will not. The lesson I have heard from my peers is: look at ways the system is being used by the users that may be different than you even anticipated. Support whatever feature is being used first and foremost. Iterate around the small successes and be very laid-back when suggesting which feature *should* be being used.
Because it is hard to predict (because human beings rarely know themselves whether they will use a tool or not for the long-run but will often say 'yes' if you ask them enthusiastically) potential success of your system (Microsoft has thrived on only investing in their solution AFTER it has been proven to be used by a marketplace) our lectures would not have been too concrete in terms of practical knowledge for you to take with you. If you enjoy the Web and believe in collaboration as an important skill for humanity, go forward with the skills you are developing and record as much about your experience as you can. You might just find you are part of an anthropologically interesting part of the human story.
What if the Web is changing humanity drastically but at a rate we are incapable of detecting? If that turns out to be the case, you are here at a very significant place in human evolution (I must think you feel that way anyway for whatever phenomenon you fancy). What if 500 years from now they speak of us the way they speak of Magellan, Cabot, Cook, and all the 'great' (I put that in quotes because not everything was so great (good and bad is bound to be the case)) discoverers on the high seas?
Perhaps that motivation will keep you moving forward when political, cultural, corporate, financial or whatever walls you encounter start to provide self-doubt and angst. At worst, you will learn a lot about human behavior and the human condition (which is just enthralling to consider in relation to the natural backdrop you are aspiring to). That knowledge will serve you well.