I guess you don't see this at an average construction site. [Ingo Rammer's DotNetCentric]

Actually, I've been getting irritated with this business of comparing software to building houses (or any building) for a while now.  But aside from Ingo's good points about flexibility and abstract vs. physical construction, the other side of that is that I think that people who haven't actually worked on a construction site have this idealized vision of how a building is built.  Believe me, it's not as rational a process as people would believe.  My brother-in-law is an electrician, my wife's uncle pours concrete, and I hear all kinds of stories.  The concrete ones are great, if you let a mixer sit too long, it's a real mess to fix!  That brings up where I was going with the whole construction reference.  I think that construction is useful to a project manager: you have to understand how to do scheduling really, really well.  I've known a few people who've worked as a scheduler for construction sites; it is a stressful job.  In fact, you have the opposite problem as in software: if a piece is missing, you can write a stub to fill in the missing piece.  In building, you can't frame the house until the foundation's poured.  You can't schedule the drywall before the electricical and plumbing is done.  And if the electrician doesn't show up or is delayed, then the drywall guy is delayed, and that delays the painter... you get the idea.  And if the electrician doesn't show, they might not fire the electrician; they might fire the scheduler.  That's why these people's jobs seem to consist of browbeating the subcontractors, trying to keep everyone on schedule.  But Ingo's absolutely right, building a house is a lousy metaphor for building software.  What's better?  I was thinking maybe filmmaking.  There's an abstract form with visible results, but the participants often don't see the finished product until it's released.  I don't know.  Building software is like building software.

On another note, I have a friend who's an architect (as in buildings); he jokes that he wants to file a class action suit against people calling themselves "software architects" - an Architect has to go through this whole licensing and certification process; we just declare ourselves "architects" :-)  I actually have a whole other piece on the idea of drawing blueprints in software design, but I promised myself I'd write some code today.  More work, less pontificating!

I had an email exchange recently with a fairly popular CTO and author. His position is the university computer science department should be a training ground for the current software trend. So the decision CS departments should be making now is dotNET or J2EE.

Of course I disagree. But I am more than apparently in the minority.  [Patrick Logan]

I'll join that minority.  I sometimes say, only half joking, that the best training for a wannabe programmer is to go work on a construction site.  Not only will you get an appreciation for how lucky you are to be in this profession, but you'll learn a lot about how to build things. I knew so little about computers when I started college (as a music major) that I had to ask the lab tech to show me how to save my music history paper in WordPerfect, yet I do pretty well at this stuff now.

Let me say this: one of the best things I heard in college was in my pre-Calculus class.  One student, a journalism major, was complaining about the applicability of pre-Calc (required for a BA at University of North Texas) to her chosen profession.  The TA said something like "look, if you just want to learn a skill, go to ITT Tech.  The point of going to college isn't to learn a trade, it's to make you smart".  I learned so many things in college that I will probably never use again, but made me think differently and learn how to solve problems.  That doesn't say that only college graduates can do this (one of the best programmers I know went to ITT), but if you go to college with the trade school mentality, you'll get a trade school diploma.  The thing is, if you learn pretty much any computer language, you can learn any other computer language, but there will always be a shortage of people who understand how and why things work, and how to create things that work.  Ever try to find a good car mechanic?  How about a really good handyman?  There's nothing magic about computers.  They're just machines.

Since Justin's been issuing qotd's lately, I thought I'd drop one that's been on my mind this past weekend:

There are nowadays professors of philosophy, but there not philosophers.  Yet it is admirable to profess but it was once admirable to live.  To be a philosopher... is to solve some of the problems of life, not only theoretically, but practically. [Henry David Thoreau]

Sam Gentile: I have seen a lot of postings on REST ... vs. SOAP...  someone please articulate in a sentence why I should care...

Analogy: ...within databases, you will likely find that something like SQL is great for queries, but you want to step back into the [stored] procedure world for updates.[Sam Ruby]

This is a pretty good analogy because SQL is a unbelievably limited query language just as REST is an unbelievably limited, er, whatever it is supposed to be.[Patrick Logan's Radio Weblog]

I guess I didn't quite get the analogy and still don't understand what REST is and why anyone should care. I still maintain that SOAP is building very functional and important systems today.[Sam Gentile's Radio Weblog]

What is REST?  REST is an acronym that stands for hypeRtExt tranSport proTocol.  I hear it's the next big thing in computing :-) 

OK, removing tongue from cheek...  I doubt I can do it in a sentence.  I doubt I could convince you at all.  And I won't argue your second point: yes, SOAP is building very functionnal and important systems today.  I've even helped build one.  Well, a functional one, we'll see about important :-) 

I don't think that I debate for debate's sake, and I like to remind myself that I don't get paid by the word.  I'm getting involved in this digression for a couple reasons:

1. I've always wondered why HTTP defined all these methods (PUT, DELETE, etc.) that seem useful but nobody ever uses them, at least not so you'd notice.  Or maybe I haven't been paying attention.
2. I've noticed that the GET binding in .NET is the most immediately approachable part of SOAP, probably because of its use in DefaultWSDLHelpGenerator.aspx.  However, I've got some SOAP GET URLs in my history list that I use frequently.  So GET is certainly useful to SOAP.  However, you make some sacrifices with GET, in .NET systems at least (SOAP extensions, for instance).
3. I'm not ready to dismiss out of hand the concerns that Eugene Kuznetsov raised at DevCon: the current web is architechted for GET requests and a request:response size ratio that's way out of line with what you'd observe for a SOAP system.  My employer has been through this before.  It's easy to gloss over those issues in development, but  network issues like that are real problems when you work on a big scale. 

I was speaking tongue in cheek when I started, but REST is just putting a new name on what we've been doing for years, along with asking people to think about how they build web systems.  I know that I've worked on some systems that could have benefitted from handling the GET / POST distinction better.  So if somebody can give me some guidelines on how to build a better web based system, bring them on.  I surely don't know the answers.