| H: |
Thanks very much for being here today with us, Professor
Poi. |
| P: |
It's my pleasure to be here, Dr. Hacker. |
| H: |
Professor Poi, the students in ICS 413 and 613
have been dutifully hacking away on their Account Info projects, but as
they start to really think about their designs, there is a growing sense
among some of them that they don't really understand what the ultimate
goal of the Account system is. Without that understanding, how can they
most effectively design the system? |
| P: |
That's a very astute observation. I would
give those students an A. |
| H: |
OK, I'll do that. From the perspective of
Extreme Programming, the students seem to be suffering from the lack of an
"onsite customer". Unfortunately, we haven't covered XP
yet, so they don't know this. They just have a vague uneasiness that
they don't really know what's going on. |
| P: |
Yes. I've always said that are two
flavors of cluelessness in software development: inevitable and
avoidable. Some kinds of cluelessness are inevitable: you simply
can't know for sure, for example, how your users will react to your system
without actually building it and then doing some high quality
observations. However, other kinds of cluelessness are avoidable, such as
a failure to actually attempt to interact with your customers as an
integral part of the development process. Developers do that out of
ignorance, fear, or arrogance, but cluelessness is the result all the
same. |
| H: |
Interesting. But back to the issue at
hand. Can you help us get a little more clueful about where we're
going with this system? |
| P: |
Well, I can give you a sense for my goals and
hopes for the system. I'm not sure how we'll get there at this
point. To begin with, at one level, I'm interested in exploring the
domain of academic department web services. If you look at an
academic department, there are lots of opportunities for web services to
improve the quality of the academic experience for students, faculty, and
administrators. I've been building a list of some useful services over the
past several months... Wait a second, let me try to find it. |
|
(rustling of papers is heard in the
background.) |
| H: |
Professor Poi, for someone who portrays
themselves as the epitome of high tech sophistication, isn't it kind of
archaic for you to be writing things down on paper? |
| P: |
Well, I do have a Palm Pilot, and when I first
got it, I was of course quite infatuated and recorded everything in
it. (more paper rustling noises) But, it turns out that for me
at least, there are some things where paper and pencil is simply the most
usable medium for the job at hand.
OK, I've found it. The list is kind of long, so I'm just going to read
it off and not talk extensively about what each service would do:
- A news service that supports email broadcast of interesting
announcements (and reminder emails about events) to interested people
in the department;
- A job listing service where local employers can post information
about their companies and current (or ongoing) job opportunities;
- A profile service where users (including undergrads, grads, faculty,
staff, alumni, and employer affiliates) can indicate their interests,
contact information, and so forth.
- A textbook exchange service where users can post texts for sale (or
texts wanted) and hook up with each other;
- A tutor service that provides a schedule for when departmental
tutors are available, what their areas of expertise are;
- An FAQ service that posts questions and answers regarding the
department or particular courses.
- A registration service that allows people to register for an account
on the system, allowing them to participate in the various
services. Most of the site's services are not publically
available.
- A resume service that allows people to post their resumes and allows
employers to search for resumes of interest. This includes a
notification mechanism, so that employers will be automatically
notified via email when a resume of interest comes in, and students
will be automatically notified when a job of interest gets posted.
- A "what's new" service that serves as a kind of
departmental electronic newsletter. Anyone can submit items, and
they are automatically collated together into a web page. A moderator
approves content before it goes out.
- An update notification service that sends an email to each
registered user once a semester, informing them of their current
settings on the site, and requesting that they update their
information if necessary.
- A curriculum planning service, which allows students to plan out a
future schedule. The curriculum planner can help students figure out
the sequence of classes they need to graduate (and how long it will
take them). It can help the department to plan courses by
understanding what students are hoping to take in upcoming semesters.
- A professional skills inventory service. There are many skills that
the faculty hope students will acquire while they are in this
department. The inventory service can help students to assess
how they're doing and suggest ways to improve their skills. It can
help faculty to better understand how they are succeeding and failing
in preparing the students for their life beyond the university.
- A student course evaluation service. This would allow students to
provide anonymous feedback on courses. (There would have to be some
constraints on what constitutes an acceptable posting, and since only
registered users could post, the department could take action if
someone is promoting violence, for example).
- An opinion poll service. Frequently, an issue will come up in
which the input of the department would be useful. For example, should
we provide Linux in the grad labs? The service would send an email
containing a link to a web page where you could answer the opinion
poll in less than a minute and the responses would be collated
together and posted in another web page accessible to everyone. Since
only registered users could vote, duplicates are avoided.
- A technical report library service.
- A calendar-based interface to department events and seminar room
reservations.
- An alumni service, which enables graduates of the department to
remain connected with what's going on.
- An image map interface to the department, that shows the floorplan
of the department with clickable images over each office to find out
who lives there and other information. The image could be
updated in real time to reflect, for example, which faculty have
office hours scheduled for that moment in time.
|
| H: |
Holy smokes, Professor Poi. That's a huge
list of services. That will take years to implement completely. |
| P: |
Yes, it will, and I'm sure that as the project
starts to take off, we'll come up with at least as many additional useful
and interesting new services. |
| H: |
OK, so reading between the lines on your paper
(which has obviously seen better days, by the way, I can see the coffee
stains), the Account Info project is the first step towards
this. But when I look at these services, I see the potential for
Account Info to be almost everywhere. A user is involved for initial
registration, for the profile, for the future curriculum, as an author of
technical reports, as the creator of a resume, and so forth. I can
feel a massive relational database design project with Account Info as its
centerpiece forming in the back of my head. |
| P: |
I know. The feeling is
indistinguishable from a migraine, isn't it? |
| H: |
Spot on. You're caught between two
problematic situations. Either you try, on the one hand, to design the
database for all of these services up front, and then engineer in a bunch
of complexity that you won't benefit from for months or years or maybe
never at all if the service doesn't get implemented. On the other
hand, you could design a minimal database to begin with and then
constantly modify its structure each time something new is added, but
that's going to lead to database schema incompatibilities and version
upgrade problems and so forth. Yikes. |
| P: |
In addition to that, you've got a maintenance
nightmare. Assume you're a poor student who wants to make a change
to the curriculum planner. Now you have to understand the database
schema for the entire system in order to make sure your change to the
schema won't have a ripple effect on other systems. |
| H: |
So how do we get around that? |
| P: |
My view is that we should attack this project
as a set of loosely coupled "plug in" web services that
communicate as little as possible between each other. Each web
service maintains its own database (which could be as complex as a
relational database, or as simple as a properties file). Each
service also exposes a "service API", which is a set of methods
that other web services can invoke in order to access information from
that web service. The benefit of this approach is that people
should be able to more easily figure out how a single service works
without having to wade into a huge monolithic underlying relational
database. |
| H: |
The problem, of course, is that you're going to
have constant problems with redundant information. You're completely
throwing out the goal of normalization. |
| P: |
Precisely. I claim that in this
situation, normalization is a bug, not a feature. |
| H: |
Whoa. Don't say that too loud. I can hear
the ICS 321 professors freaking out already. |
| P: |
Look, I like normalization. Some of my
best friends are normalized. Normalization is great when you
have relatively static and relatively well understood requirements, and
where efficiency and data integrity are mission critical. But
software development is always about trade-offs, and you don't gain those
nice benefits without losing something else. What you lose with a
highly normalized information system is flexibility and the ability to
understand one part of the system in isolation from the rest.
Normalization is a kind of optimization, and optimization virtually always
results in tighter coupling among system components. |
| H: |
So you're designing this system to be hacker
friendly, at the expense of an occasional burp in data integrity, such as
a user temporarily being characterized as an alumni in one part of the
site but as a student in another part of the site. |
| P: |
Exactly. By the way, you and I both know
that when we refer to Hacker, we are referring to its traditional,
honorable use of the term, as opposed to Cracker, those dishonorable
pest-like script kiddies who break into systems and cause mischief. |
| H: |
Believe me, with a name like Dr. Hacker, my
intentions are misunderstood continuously. So getting back to Account
Info, the idea now is that this will be a very minimal representation of
users, just enough to find out who exists on the system and so forth. And
a web service could, for example, request a Collection of all currently
defined users in order to accomplish its task. |
| P: |
Quite so. The idea of hacker friendly
brings up one of my other goals for this system. I would like to see this
system developed, deployed, and evaluated initially in the ICS department,
but then released as an open source project into the wild. |
| H: |
Cool. So it might be hosted on source forge or
something? |
| P: |
Yes. If you would permit me to fantasize a
little, I'd love to see the ICS students in this department be responsible
for developing not only the best academic department web site in
existence, but also responsible for designing it in such a way that it can
be adapted and installed in other departments as well. |
| H: |
Kind of like the Tomcat of department web
sites? |
| P: |
Yes, a kind of reference implementation, with
source code fully available, that is used by many departments all over the
world, that is enhanced and extended by dozens or hundreds of hackers to
keep up with new technologies and ideas, but that is sponsored and managed
by a continuing stream of ICS undergraduates and graduate students in
software engineering. It would be something that would give every ICS
software engineering student a world-wide reputation in academia. |
| H: |
That's a nice fantasy. So what are you
calling this system? |
| P: |
I have no idea. I'm hoping the students
will come up with something. |
| H: |
Well, Professor Poi, that's all the time we
have for today. Thanks for being with us. I hope you'll stop
by again soon. |
| P: |
It would be a pleasure. |
|
|
