-------------------------- after the first class

Thanks for showing up to the first class of 6.171 and for not walking
out halfway through.  That's always a good sign.  Note that as the term
progresses an increasing percentage of the course meeting time will be
devoted to team presentations and discussions.  So if you thought the
lecture was boring don't fear; it will be one of the last.

http://philip.greenspun.com/teaching/6171/2003-fall/calendar is up to
date with all of the assignment due dates.  Note that the first
assignment is due a week from today.  It is the exercises in the Basics
chapter of http://philip.greenspun.com/internet-application-workbook/.
This is an individual assignment, like the mid-term exam.  You can
collaborate with another student but you should note that on your site
and make sure that you really understand every line of code rather than
dividing and conquering (an acceptable technique for later assignments).

It might turn out that you've installed Linux, Oracle, and a Java Server
Page interpreter to do the Basics pset.  When teams are ultimately
formed and projects assigned it may transpire that, to get the partner
and client you want, you must switch to Microsoft .NET (or vice versa).
That's painful but unavoidable.  The important thing is that you've
learned to install an environment yourself and gotten it to do something
useful.  If you end up spending the rest of the term developing on your
friend's computer, that's just fine.  If you need inspiration, or want
to steal source code, http://ninja.mit.edu/basics/ seems to be fairly
complete already... (hints to Sebastian: (a) if you sign all of your
pages with your email address at the bottom you'll be able to get
helpful feedback from users, and (b) you might be able to shoot more
accurately if you hold the pistol with only one hand)

[Oh yes... sorry to have to strike a harsh note but we automatically
drop from the class anyone who hasn't turned in the Basics pset by the
deadline.  Our experience has been that people who don't get this done
on time fall hopelessly behind, can't recover, and drop the class.  A
team that loses 33% or 50% of its members during the semester is
unlikely to be successful.  So please decide before the 3rd class
whether you're in or out!]

http://philip.greenspun.com/internet-application-workbook/grading-standards
contains a more detailed exposition of our expectations for the semester
(discussed in class today).

On to the projecsts...  If you know someone who wants to be a client,
the deadline for filling out a client questionnaire is Sunday.  The form
may be obtained at
http://philip.greenspun.com/teaching/6171/client-questionnaire.  By
Sunday evening or Monday at the latest we'll spam you with a Web page
detailing all the potential clients and the text of what they wrote to
us.  You should look at this before Tuesday's class so that you have
some perspective on your options (we'll only hear from about one quarter
of potential clients because of limited time and the fact that many
clients are not local).  Prepare to be critical in class.  If the
clients are in the room you might want to avoid words such as
"pinheaded", "idiotic", "pointless", etc., but still you want to be
skeptical and probing to make sure that a project really makes sense for
the proposed users.

Using a little Web system that Ben whipped up you'll form teams and put
in bids for clients (perhaps ranking 1 through 10).  By Thursday the
11th we'll take all of these preferences and try to come up with fair
and fun assignments.

I'm going up to Moosehead Lake, Maine for the big seaplane fly-in
weekend so I won't be reachable until Monday morning, but feel free to
contact Ben Adida (ben@mit.edu) with questions.

Philip

----------------------  before the discussion forum presentations

In 6.171 class on Tuesday we'll hear presentations of different
discussion forum designs.  An outline for the presentation is available
in http://philip.greenspun.com/internet-application-workbook/discussion,
right underneath Exercise 5.  Note that this presentation requires a
paper handout, of which you should make at least 15 copies.  The handout
should contain all of the relevant SQL: data model, queries, and
execution plan for those queries (use the EXPLAIN command in PostgreSQL;
for Microsoft SQL Server there is undoubtable some wizard to do it all
for you).  By having the SQL in front of everyone we'll maximize the
chance that people will be able to offer each other truly constructive
criticism.

Each presentation is going to be about 7 minutes long and then we'll
have another 7 minutes for discussion.  Dave Mitchell will be coming in
to critique project management documents (I hope that they are all up to
date on your servers because he is only going to be able to work from
what he sees).  Here's the schedule:

11:35-noon:  Dave Mitchell show
12:00-12:15: Michael Ogrydziak presents the greenspun.com approach;
             Sebastian Ortiz gets the first response
12:15-12:30: Sha Ma presents the Cambridge Ent. Club approach;
             Amerson Lin gets the first response
12:30-12:45: Alex Vandiver presents the MIT Technique approach
             Ian Spivey gets the first response
12:45-12:55: Vishy Venugopalan presents the HP approach
             Jason Goggin gets the first (and probably only) response

Note that these presentations have been assigned to specific people
within teams.  Other team members can run the Athena workstation but we
ask them not to talk during the presentation and not to respond to
questions.  An attempt here is being made to (a) hear from some voices
that aren't always prominent in class, and (b) to get a first response
from someone using a different set of tools than the presenters (e.g.,
.NET hackers respond to PHP/Postgres developers).

------------------------ refined discussion forum presentation,
                         pre-scaling

Teams' discussion forums seem to be functioning rather nicely
(congratulations!).  Thus it isn't the best use of class time to run
through 8 10-minute presentations that scratch the surface.  Instead
we'll do 35-minute meetings with course staff (bring a laptop if you've
got one) in different corners of 6-120.  Hal and I are both out of town
on Tuesday so Andrew, Ben, and Tracy Adams (Internet application
developer for nearly 10 years) will be the coaches.  This means that you
don't have to show up for the whole class period unless you want to
listen in on some of the other sessions and see how other teams are
solving problems.  If you're on "scheduled separately" try to make a
date with Andrew or Ben via email or in person ASAP.

One of the purposes of the meeting will be to help you improve your
answers to the Scaling Gracefully exercises.

Here's a proposed structure for your meeting:

1) have your coach browse around looking at existing discussion forum
   postings, try to reply, be forced to log in, register or log in,
   reply, log out, log in as an admin, moderate;  Now your coach is
   familiar with the look and feel of the site

2) show your coach a diagram of how your system is architected including
   the Web server (1 or many processes?), RDBMS (which brand?), and how
   many computers these programs are spread across (usually this is just
   one during development)

3) walk your coach briefly through the queries that are executed to
   generate a "show one thread" page from the discussion forum and any
   queries that are executed frequently system-wide.  Come prepared with
   "Explain plan" output for these queries.

4) show your coach the source code for your main user pages in the
   discussion forum; ask for his or her opinion on the level of
   documentation and the way in which you've used shared procedures

5) show your coach your plans for the rest of the semester, including
   the schedule and risks

11:35-12:10

Tracy Adams: Condo Project
Andrew Grumet: MIT Technique
Ben Adida: Creative Commons

12:15-12:50

Tracy Adams: Ziff Davis
Andrew Grumet: HP
Ben Adida: Dspace

---- scheduled separately ---

Ben Adida:  greenspun.com
Andrew Grumet:  Dspace

--------------------------------------- after the Planning Redux meeting

We've gotten to the point in the semester where the kinds of problems
that are typical on industrial software projects begin to emerge.  The
biggest challenge comes from requirements changes.  The teams that have
been doing electronic versions of established paper processes or
redesigns of existing Web services have had the fewest requirements
changes.  That's as expected.  What about the clean sheet of paper
designs?  The classical approach to software development involves months
of design work and voluminous specifications before any code is
written.  The theory is that with enough hard work, the project
requirements can be determined in advance.

What inevitably happens with "the big spec book" approach is that, once
the application is up and running, the customer and users discover that
there are a lot of other things it should do and the application needs
to be respec'd and rewritten, resulting in delays (see the "War Story"
in the sidebar of http://philip.greenspun.com/seia/metadata for a tale
of how some friends and I dealt with this on a particular project).
That's why there is such a stress in 6.171 on getting a functional
skeletal prototype up and running as early as possible.

We looked at the East Asian bibliography project in some depth
yesterday.  It makes a good example because the customer disagreed with
all but one of the survey questions in the Planning Redux chapter.  As
noted by Tolstoy in the opening of Anna Karenina, "All happy families
resemble one another, but each unhappy family is unhappy in its own
way."

What could Marios and Fivos have done differently and how can they
salvage the project and the client relationship?

The East Asian site is primarily a data entry site.  The main thing that
could have been done differently was to get the data entry pages up
faster in a form that looked more final so that the customer would be
encouraged to test the critical procedures.  When dealing with
non-technical users, appearance becomes critical.  The irrelevant
iPod-style photo at the top of the home page, which then got a big red X
through it.  The boxes on the screen that say "put something in here for
the inputter".  All of this communicates to the client that "this site
isn't ready to be tested" and the client chooses to do other things with
his busy day.  Slick design isn't important, but a plain text complete
workflow is.

What about listening to the customer?  At HP, before Carly Fiorina took
over and pushed the company into the tank, they used to say "The
customer isn't always right, but he is always the customer."  Does this
mean that you do everything the customer asks?  No.  I was shocked to
hear Marios and Fivos defending their practice of using a text string
(for the book title) to associate book chapters records with book
records, rather than a REFERENCES constraint and database ID.  That the
client thought this was okay is not relevant.  This, like almost
everything else in the data model, is an engineering decision that needs
to be made by an engineer.  You let the customer say "It is an absolute
requirement that book chapters be associated with books," but then you
figure out how to model that.  The client doesn't know SQL and doesn't
know what a database management system can do.

On the other hand, when the client says "I need streamlined input
process with a custom entry form for all 12 types of bibliographic
record", an engineer should take that seriously rather than saying "But
that means my clever auto-generated form page won't be adequate".  Only
the client understands the business process requirements.  If it means
grunging out some custom forms, you have to grunge out the forms (or, as
we saw in class, add a whole lot of extra columns specifying the user
interface to your fields table).

Speaking of requirements changes... early in the semester, you all may
recall the debate over whether it was acceptable to use LaTeX/PDF for
documentation.  The East Asian team rejected the advice of successful
software developers such as Jin S. Choi and installed a minor compromise
(adding HTML output from LaTeX so that the out of date docs could be
easily viewed in a browser).  I said "If you add those extra steps
toward keeping your docs up to date, it will become out of sync with the
site."  In class yesterday we learned that the docs are in fact already
out of sync with the code and the data model.  Lesson: it shouldn't be
harder to change the docs than the source code.  Nearly every Web
development environment provides a scripting style of changes where the
programmer simply edits a file and the new software is live.  I.e.,
they've dispensed with the compilation step.  Marios and Fivos added a
compilation step (running the LaTeX compiler) to the documentation
change process, and the result (code changes without corresponding
documentation changes) was as predicted.  (The other variation that
we've seen on the traditional "docs are files in the files system along
with the Web scripts" is the East Coast Aero Club team's installation of
TRAC and the resulting editable-from-a-browser documents; it seems to
have worked out reasonably well and you could argue that on their site,
the docs are easier to edit than the page scripts.)

The other show-stopper issue that we looked at in class yesterday was
hosting and sysadmin on the iCompact site.  Programmers tend to devalue
sysadmins as fat losers who wear cell phones on their belts, but
apparently it isn't as easy as it looks.  This is a risk that needs to
be reduced early in the project.  This is the first year that students
in 6.171 have relied on external hosting companies rather than setting
everything up on a PC in their living group.  So for the first time, we
are hearing "I had to do it that way because Ruby doesn't really support
SQL" and "My hosting company sucks" and "My hosting company won't let me
install X".  The infrastructure gets better and the software engineer
becomes progressively more helpless?  I'm not sure that this is
progress.  One lesson I would draw from this is that, for our kinds of
projects, a self-administered box is probably better than a server
administered by a typical hosting company.  Remember that the average
Web site is static HTML and therefore the average hosting company is set
up to do a good job for that.  The RDBMS-backed Web site is still
comparatively rare, which is why you don't see Amazon.com outsourcing
its hosting and running the site for $15/month.

--------------------------------------- after the Planning Redux meeting
                                        (2nd)

I'm finished with the client surveys now (you can find them in the
evaluations subdir).  One common theme that I've found is that the
clients aren't being walked through the documentation and aren't being
shown the user testing process.  In some cases, this isn't so bad
because the client is happy with the product and doesn't care about the
process.  You're selling yourself short as an engineer, however, because
the client doesn't have a chance to see some of the hard work that
you've done and won't say, in a recommendation, "these guys planned out
every step and conducted such great user tests".  If the product isn't
meeting the client's expectations, it becomes a lot more critical to
demonstrate that your process is sound.  Otherwise, the client will lose
confidence and therefore interest in the project.  Don't forget that
your team includes people on the client side who have to provide
content, testing, promotion, etc.  You need to keep them motivated and
on schedule (so your /doc/ directory needs to have a schedule including
tasks and deadlines for the client
(http://pomo.is-a-geek.com/doc/TextbookExercises/ImplementationPlan.aspx
is an example)).

-------------------------------- 2nd to last week of the semester

The end of the semester is in sight.  That means that you will probably
won't get everything accomplished that you expected to accomplish, at
least not by next week.  So... what's more important, one extra feature
or cleaning up the documentation?  If you want to distinguish yourself
from the average computer programmer, the answer is "documentation."
One of the things that I tried to drum into folks this semester was to
think and write before coding.  I don't think that I succeeded.  It
could be just one page saying "After a conversation with the client,
these are the kinds of user activity questions the admin pages and
reports should be able to answer..."  I was dismayed to see projects
where the user activity pset hadn't been done.  I was a lot more
dismayed to see that this one-page document, which would take no more
than one hour to produce, hadn't been done.

Programmers are a dime a dozen.  If you have carefully written down what
needs to be done, what questions need to be answered, and what services
need to be provided, you can probably find a cheap pair of hands to do
the work.  If, on the other hand, the goals and requirements of the site
are a complete mystery to all concerned, there is no way to add labor to
the project effectively.

If your application performs the basic functions that the client needs,
there is no shame in not finishing out the corners.  In fact, you can
take pride if the corners are at least loosely specified in a
clearly written document.


------------------------- after the first panel

Thanks to everyone who presented today.  I think we were fortunate to
have a good panel of typical decision-makers.  These are the people who
decide to fund projects, retain software engineering teams, etc.  If you
can impress people at this level, you won't have to spend the rest of
your life working for someone else.

Here's my critique of the presentations, in hopes that these thoughts
will be useful to the teams presenting on Thursday...

EAST COAST AERO CLUB

Lev needs to deliver his words more slowly, especially the critical
words such as the elevator pitch.  The talk should start with more of
the business problem and be more clear about the status of the project
(launched, 100+ reservations handled so far, launching to a wider
audience on Sunday).  The site demo should be shorter.  These are
business people, not users or admins to be trained.  For the business
people, you say "this is the problem that I solved, here are some
numbers on how much it cost to build, how many people are using it right
now, and how much money it is bringing in (or saving)".  Now you have
their attention.  You show them enough screens of the site so that they
get a feel for it, maybe a user accomplishing one task and an admin
accomplishing one task.  You don't go on long enough that they get bored
or have no questions.  If they want to see more of the user experience,
they will ask.

The ECAC presentation needs to have one slide showing the server
resources and configuration.  Notice how concerned everyone was about
maintenance.  One way to predict maintenance cost and difficulty is to
count the number of servers and systems.  It would have been reassuring
to show that the entire site was running on small machine (or a slice of
a small machine) with not too many processes talking to each other.
Given what Lev and Brian presented, the panelists were free to assume
that the ECAC site was served by a cluster of massive machines, each of
which would require a full-time guardian.  One slide showing hardware
and software, with the monthly cost if outsourced or capital cost if
in-house, would have answered a lot of questions.

Notice how thrilled the panelists got when they found out that the site
was actually being used.  These are guys who have lost $millions
investing in software that everyone agreed was really useful... until it
was launched.

Lev and Brian scored a lot of points by handing out the writeup, I
think.

[Some things that I noticed about the application... The approval page
has a huge amount of extra detail, e.g., the database ID of a
reservation.  Why is the user seeing database keys?  Similarly in the
billing form, the user ID shows up with the clever Ajax.  If you need to
distinguish between two users with the same name, much more likely the
dispatcher would want to see their ages (Tom Lee, 67).  In one of the
admin page reports, I saw a summary of transactions.  An aircraft was
identified in the report by tail number.  How come I couldn't click on
that tail number and get the data for just that aircraft?  The
information should be the interface.]

The presentation could have been a lot better.  On the other hand, the
application is good and real users are getting benefits from it, which
is more than most programmers can say about their work.  So Lev and
Brian will get respect whenever they talk about this.

UNDERGROUND GUIDE

When presenting this in the future, I think it will be worth taking
Cesar's suggestion to pitch the whole thing as a careful attempt to
increase the response rate.  The computerization of a formerly paper
process is overly familiar to most business folks.  Notice how
unimpressed Jamie the venture capitalist was.  He doesn't feel the pain
of all the HKN editors, of course, but we have to take his perspective
seriously.

Speaking of "editors", I think it would be much more clear to an
audience if you used that term for the people who assemble the user
contributions into the finished articles.  They are in fact editing
text and performing the same kind of function as an editor at a magazine
or newspaper.

The demo was way too long.  A few carefully chosen screens would be a
lot better.  Let them ask if they want to see more!  Business folks have
no trouble believing that a programmer can write code, so they will
assume that there is a lot of stuff in your site.

It looks as though a visit to a user interface expert, such as Julie
Melton on the 6.171 staff, would pay a lot of dividends.  The panelists
got hung up on small stuff, such as the Finish button remaining live
when the user was on the Finish page already.  Someone like Julie would
have pointed this out a long time ago (you might have to invest in a
subway token to meet her at HBS with your certificate-enabled laptop).

ICOMPACT.COM

I've got a phone call into Aimee to find out how things have looked from
her perspective.  I already sent an email to the team with some
conjectures.  The reason that I liked this project to begin with was
that it was so launchable; it seemed as though a high-quality discussion
forum would be enough to support the users and the extra features could
be added with a lot of real user feedback.  When the site didn't launch
in early April, however, it was almost inevitable that the site wouldn't
launch this semester because the client is a law student and wouldn't
want to do something potentially risky and time-consuming around her
final exam period.  What could make Aimee think that throwing the big
switch might be risky and time-consuming?  Well.... the development
server was always slow and clearly wouldn't have supported a production
number of users.  The atMyPad folks had this problem too for most of the
semester.  There is some level of peformance and solidity below which a
client will lose faith that you're ever going to be able to get it to
work.

The panelists asked about an RSS feed and seemed disappointed that the
new site didn't have one.  It is a good thing that they hadn't read

http://philip.greenspun.com/seia/distributed-computing

and realized that an RSS feed was in Exercise 8 and a required minimum
part of the course work!  The panelists aren't technical, but Cesar has
installed Linux, set up Oracle, and installed our old ArsDigita
Community System toolkit.  He has written SQL code and Web scripts.  He
knows that he could write an RSS feed in a few hours.  He also knows
that any site that wants to keep its hooks into readers needs to have an
RSS feed.  Lesson:  if you don't do the stuff that the decision-maker
thinks is easy, you'll have a hard time convincing him or her that a
delay is caused by a real technical challenge.

[Some nits on the application...  There were a lot of typos on the
overview doc page, visible at a glance to the panelists (e.g.,
"disucss").  On the profile page there were headlines for some areas and
"show details" links, but there were no summaries of what you might see
when you clicked on those "show details" links.  If there is a "details"
option, why aren't we seeing a summary to begin with?]

SUMMARY

We have four teams to present on Thursday, which means we have to stick
closer to the schedule.  Here are some ideas for speeding things up and
keeping the panelists happier:

1) paper writeup/overview handouts (the panelists won't ask as many
   questions because they will think that they can do self-service after
   going home), including your names, contact info, and the URL of the
   service

2) start with clear exposition of project status, how many users, when
   launched, etc.

3) much shorter site demo

PS 

It would be good form to thank these guys for their time in showing up,
a personal thank-you to each one saying what you learned from him (just
pick out one thing that a panelist said that rung true or surprised
you).


------------------------- after the second panel

Thanks to everyone who presented at the second panel last week.  I think
the sunny weather made the panelists less critical than the folks on the
rainy Tuesday.  I guess that shows that one should check the long-term
weather forecast before scheduling a demo!

Here are my thoughts on the presentations...

SOLIDWORKS

I don't think the panelists were entirely fair in beating up on the team
for not having solved all of the client's organizational problems.  I
think that they couldn't find too much to criticize in the presentation
or the application, so they chose larger issues to criticize.  The most
Web-techy guy, Andy Roberts, had what I thought were the least practical
ideas, i.e., using GoogleBase and other free public services.  These
high-level IT guys will do almost anything to avoid having to hire
someone who can sit down, develop a data model, and write some code.
They want to glue all kinds of systems together instead, thinking that
this is easier.  Yet Amazon was able to get to maybe $1 billion in sales
while still using the simple "everything in one Oracle database"
approach.  And why should a company such as SolidWorks, which has a
substantial IT budget, need to trust its most private data to free
public Internet services?

Notice that the best programmer on the panel, Patrick Sobalvarro, did
not share this aversion to coding up a solution in an RDBMS.

How do you convince a Chief Technology Officer-type who is convinced
that nothing can be built for less than $100 million and that lots of
packaged software should be purchased instead (and then glued together
by consultants)?  It isn't always possible.  Best to go over that
person's head to the money people and say "this is how much we've spent
on the project so far; this is how much return on that investment the
organization has gotten."  The higher level the person in the
organization, the shorter the demo should be and the more stress placed
on summary financials.  When the Siemens executives talked about the
knowledge sharing system that Tracy, Eve, Jin, and I built for them,
they always said "We spent less than $1 million on this and it has
already won us more than $20 million in contracts that we wouldn't have
gotten."

TEXAS 4000

I think you need a day-in-the-life style of presentation.  "Rider wakes
up in the morning and decides to see how his donation collection
pipeline is doing; here is how he checks. (small demo) Ride organizer
wakes up in the morning and wants to see how the overall project is
going (small demo) Member of the public checks in during the ride, sees
the real-time uploaded photos, and decides to become a host (small
demo)."

The features of the site per se aren't compelling enough to support a
"one feature after another" style of tour.  If you're going to do that,
you would need to do what Cesar suggested and say "We looked at the 10
leaders in the area of Web support for charity athletic events and built
a system that has the following unique features."

atMyPad

I think you guys conclusively demonstrated that an engineer without a
client isn't doing engineering.  Clients may be annoying.  Users are
certainly demanding.  But both have the advantage that they have an
understanding of what is and is not a real-world problem.

Your client was a venture capitalist, Todd Dagres, famous for having
gotten rich during the 1990s boom.  Because he is rich, I guess everyone
assumes that he is therefore smart (the other possibility is that he was
lucky).  Yet we discovered during the panel that Cesar Brea, who is not
famous or rich, had vastly better ideas about what your application
should do than Mr. Dagres.  (He actually had better ideas that I did,
also!  Remember that I had never liked this project because it reminded
me of Prodigy circa 1990 or the Java-heavy Web pages of 1995 that users
rejected.  But I didn't have too much constructive to add because... I'm
mostly an engineer, not a client!)  So... star-worship is great and
billionaires are fun to hang out with (esp. if they let you fly their
turbine-powered aircraft), but they can't be relied upon for great
product ideas.

www.photo.net was my own idea.  I guess it is an okay site.
www.scorecard.org, has had, I think, a much larger impact-to-effort
ratio.  Jin and I built the site in just a few weeks as a volunteer
project.  Why was it good?  Because we got the idea, and fairly specific
marching orders, from an environmental scientist.

It isn't totally fair to beat up on Dagres, I guess.  The fact that you
guys hadn't built anything beyond a simple text blogging system by two
months into the semester might have caused him to lose interest in you
as engineers.  And the fact that your dev server was down/throwing
errors most of the time would not have inspired confidence.  Any venture
capitalist is besieged by very competent engineering teams (if he wanted
a text blogging system, he could have gotten any of those teams to
install multi-user Wordpress and tweak it).

EAST ASIAN

Good presentation!  Congratulations.  I was surprised that the panel
didn't beat you up for not having more real entries in the bibliography
this late in the semester (remember how scornful John Hirschtick was in
the first panel when the iCompact sample profile was of David).

Again, I think the "day-in-the-life" approach would have helped.  Grad
student in China wakes up and decides to enter a new journal article.
Manager back here in Boston wakes up and gets a report on what was done
in China while he was asleep.

--------------------

USE OF COMMERCIAL HOSTING PROVIDERS 

I think the overall project results and the panel reactions demonstrate
that the reliance on commercial hosting has been a failure.  This is the
first semester in 6.171 that people have had the crutches of commercial
hosting and Ruby on Rails.  The average client satisfaction has been
lower and the time to launch has been longer.  It seems as though the
low-cost hosting providers don't do a very good job and therefore the
dev sites' performance is poor and/or variable.  The client loses
confidence.  When asked questions by panelists, the people who've relied
on outside hosting can't give good answers.  If you understand something
completely because you've done it yourself, maybe you can decide to
outsource the function to free up some time and energy.  If, however,
you outsource something because you don't know how to do it, you are
guaranteed to be clueless when things go wrong and that cluelessness is
apparent to the client (and it scares them!).

So.. the $300 PC under the desk may not seem elegant, but it appears to
be a necessary starting point.

--------------

I'm going to send out individual evals and grades later this week after
going through each project one more time (wanted to give everyone a
chance to clean up code, doc directory, and user experience).

The grading standards put forward in
http://philip.greenspun.com/seia/grading-standards boil down to "did you
do something useful for the client and his or her users?"  It might seem
a little unfair in that a lot of MIT graduates seem content to draw a
salary based on credentialism and aren't very interested in whether or
not they are doing anything useful, as long as the paychecks keep
coming.  So we try to add the simpler test "Did this person avoid
completely disgracing himself and MIT by doing at least one thing well?"


------------------------- last message

The dust seems to have settled from 6.171 to some extent.  There are
hundreds of users on the SolidWorks Fans site and on the East Coast Aero
Club site.  The SolidWorks team doesn't seem to be attracting too many
bricks from the users, perhaps because their service doesn't get in the
way of people going about their daily business.  Lev and Brian, on the
other hand, are finding out that launching a business-critical
application brings out a lot of unforeseen issues.  Given the big
changes that both of these teams have had to make post-launch, you can
see why someone reading a resume would put so much stress on launched
versus unlaunched applications.  All systems sound pretty good until
someone actually tries to use them.

The Undergound Guide seems to be off to a good start as well, with more
than 250 surveys filled out and a better-than-paper response rate on
their test classes.  I'm not sure what they've had to change, if
anything, so far.

More than 50 percent of what software developers do turns out to be of
such low quality and value that it is simply discarded.  So if these
were the only two launches from the seven semester projects, that might
be consistent with industry averages.  On the other hand, I think that
there is a lot of hope for the Texas4000, East Asian, and iCompact
sites, all of which have publishers who are interested in operating the
service.  iCompact is the trickiest, of course, due to the change in
control, but I think that one could be salvaged if David and Pamela set
up their own box and make a dev site that is fast and reliable.

Those of you who are graduating... Don't forget that the only practical
value of fancy education (Harvard MBA, MIT degree, whatever) is in the
contacts you make and the first job that you get.  Don't lose touch with
the good engineers you met in 6.171.  These are the folks you'll want to
call four years from now to ask "Have you been using System X?  If so,
what has your experience been?"  A contact list like this makes you a
much more valuable engineer.  As far as the first job goes... remember
that, contrary to what the MIT PR might have you believe, an MIT degree
does not guarantee career success.  If you want to be an engineer, you
need to be able to go through the steps of your 6.171 project in your
sleep: talk to client, write down plan, discuss plan with client, build
prototype, test with users, refine prototype, launch with users, refine
launched system.  The typical MIT course is an efficient way to learn
some principles and skills, but poor preparation for the real world of
engineering because you don't get to practice these steps.  Try not to
get stuck in a corner of a big engineering project where you just do
what you're told and don't have much contact with the client or users.
That's not practice at being an engineer; it is practice at working for
an engineer.

Thanks for sticking with 6.171 this semester.  I'm sorry if the
criticism seemed harsh at times.  Remember, however, that the world is a
harsh place.  The really good programmers, the kind that are fun to work
with, such as Jin S. Choi, report that they only want to work with about
5 percent of MIT graduates.  Then there was John Hirschtick who said
that "You can teach someone skills, but you can't teach them to be a
'run-with-the-ball' kind of person."  MIT is a good school, but the best
students from big state universities will work incredibly hard because
they expect to have to distinguish themselves from the herd of 50,000
others on campus.  Zak Kohane, an MIT Ph.D. from Course 6 managing a big
group at Boston Children's Hospital/Harvard Med School, reports that he
is only satisfied with about 5 percent of his Course 6 UROPs and that
his best young researcher right now comes from Northeastern ("incredible
energy and creativity").  That doesn't sound like such a bad statistic
until you reflect that MIT is very expensive and a rather painful
experience (starting with the weather).  If University of Kansas can
graduate people who are just as good for $4800/year tuition (in-state),
there is no reason for MIT to continue operating a CS department.
So... if you felt some pressure this term, it was an attempt to get you
into the 5 percent of MIT graduates that competent software engineers
want to have around.

[When I teach flying, I don't have to bother with cajoling anyone, by
the way.  There are no flight students who think that mediocrity is an
acceptable goal.]

Here are some things that I hope you take away from 6.171:

[] The easiest way to succeed on a project is to pick a clear-headed
client with a useful idea.

[] The relational database is a great tool for controlling concurrency
and isolating precious information from clumsy programmers (and we're
all clumsy at times)

[] A good query might be O[n] compared to O[n^2] for a bad query (or a
good query into an insufficiently indexed data model), but it is tough
to figure that out and it won't matter until the system goes live and is
populated with lots of data.

[] Keeping the data model and the SQL code clean is much more important
than anything that happens in the page scripts or Web server.

[] Being a productive programmer is key, because you'll probably have to
build and rebuild a few times to reflect user feedback and client
changes of mind/heart.

[] People won't be able to tell you what they need or think until
they've seen a mostly working system.

Remember that there is almost nothing that you can build that has a
better cost/benefit ratio than an Internet application.  In the
non-profit world, this translates into big impact for the successful
programmers.  In the for-profit world, this has often translated into
big money for the successful programmers.  This is a great time to be a
software engineer, despite the competition from people in Third World
countries.  A programmer who is willing to think about users is no
longer confined to the back room in a big company.  

[Also, don't forget the business perspective of one of my flying pals.
He said "There has never been a better time to be an entrepreneur.  Big
companies have given up on trying to innovate.  The use their M&A
[mergers and acquisitions] department as R&D instead, buying small
companies whenever htey need to innovate."]

Thanks for sticking with 6.171.  Feel free to call or email if you want
my help with anything.  I'll be back from California by June 18 and will
have the new four-seat helicopter.

Have a great summer!