American Idiot is not a good album

Actually, that's a bit of an overstatement. I've only heard three songs, and while American Idiot is almost painfully trite and I change the station the second I realize that Wake Me When September Ends is coming, they're not worth a 'blog post. On the other hand Boulevard of Broken Dreams manages to be both trite and completely meaningless, all at the same time, and I think that's probably something of an accomplishment.

To be fair, Boulevard does have a point. The singer is lonely. We've all been lonely at times I'm sure, and so the natural impulse may be to sympathize, identify, etc. However, before getting too gushy, let's take a look at the lyrics.

I walk a lonely road
The only one that I have ever known

The empty road is not exactly a stunning new metaphor, but at least it's a starting point. Also, apparently the singer isn't lonely because his girlfriend left him, he's lonely because he's never had a girlfriend in the first place. Understood. Moving right along:

Don't know where it goes
But it's home to me and I walk alone

After the angst-ridden revelation that he's also unsure about his future, the singer returns to the original idea of being alone. While personally I might have spent a bit long developing that additional theme, at least he's introduced some new ideas.

I walk this empty street
On the Boulevard of Broken Dreams

If I were being charitable, I could refer to this as a development of the earlier loneliness theme, but it doesn't really introduce any new ideas. Instead, it feels rather like an exercise in creative thesaurus use, not at all hampered by the trivia that a boulevard is a road and thus walking "a street on the boulevard" makes no sense at all.

Where the city sleeps
and I'm the only one and I walk alone

Also, he's lonely.

I walk alone
I walk alone

I was rather expecting a sudden Marilyn Monroe appearance, but his walking alone is consistent with the walking alone mentioned before, as well as the lonely road and the . . . well, walking alone mentioned right up at the beginning.

I walk alone
I walk a...

Holy shit, he's alone.

My shadow's the only one that walks beside me
My shallow heart's the only thing that's beating

Another throw-away reference to something besides the "I'm alone" drumbeat here, but it's offset by the exciting new image of being only accompanied by his shadow. Wait, that's not new.

Sometimes I wish someone out there will find me
'Til then I walk alone

And I give up. Having introduced a theme in the opening lines, it hasn't been extended, refined, developed, elaborated, or even simply forgotten for long enough to be interesting again. Whatever sympathy one might have had for the singer in the opening is rapidly eroded as it becomes apparent that not only does he have nothing to say, but he's absolutely committed to driving that point home with jackhammer force. This may have been wonderfully therapeutic to write but the result isn't just bad, it's completely vacuous and frankly, there's no excuse for this being in public circulation.

Thank you. You may now return to your regularly scheduled activities.

You are in a maze of twisty passages, all alike.

Point

You may have seen this blog post before — it was linked from Slashdot. Its author demonstrates the other kind of backwards thinking that perpetuates computer science/software engineering today. He's not overly concerned, at least in that post, with management techniques, models, waterfalls, etc. Instead, he's deeply concerned that computer science graduates these days haven't taken courses on XML, XST, XForms and XWhateverTheHell that his company uses to develop corporate web sites.

Frankly, I don't get it. First, what singles out the development of corporate web sites as being particularly worth focus in a CS curriculum? Is he really claiming that XML formats are so inordinately complex that people should have to devote entire college courses to them? Personally, I disagree. Just as I would claim that anyone who can understand a rich text editor can understand HTML (or TeX or whatever your document markup language of choice is), I would claim that anyone who can understand HTML can grok XML. We aren't talking about a paradigm shifting approach to computation here; we're talking about structuring documents in nested blocks surrounded by little pointy brackets.

Second, where do people keep getting the idea that college is supposed to be career prep? If past history is any indicator, XML will be about as relevant in twenty years as COBOL is now: it'll be around in a lot of legacy systems, and everyone who can will be using something new involving an even more exciting letter than X — maybe Q. I'd ask our author the same thing I ask everyone who's intent on teaching all sorts of Microsoft toolchain-specific stuff: will your students understand the next technology to come down the pipeline? The next after that? If it turns out next week that everyone is using S-expressions and Scheme, how quickly will your company be able to adapt? The key to this kind of thing isn't a detailed knowledge of individual frameworks (platforms, services, et. fucking. cetera), it's knowing how to think. That's where college comes in. You can teach XSLUT on your own time.

(Thankfullly, many of the comments already posted on his 'blog make the same point I do.)

Counterpoint

There's been a flap lately about Cuba's offer to help out in the areas affected by Hurricane Katrina. I believe China's been in on the same game, and there have been quite a number of offers of aid that have been accepted — from the UN, NATO, the EU, etc. — but I'll focus on Cuba because they make an easy target.

To start, though, I'm not really trying to make a point one way or the other about the way the US government has responded to Hurricane Katrina because I think just about everyone from just about every color of the political spectrum can agree that it's been fucking awful. In fact, given that the company I work for makes planning and coordination software that would have oodles of uses in situations like this (if only Homeland Security would pay us to develop it), hey, pile on.

But getting back to Cuba: whatever you may think about everything that's been going on in this country, it's hard to miss the fact that Cuba's "aid offer" is a political move. Cuba, frankly, is not in very good shape right now, what with the grinding poverty and the starving citizens and what not. Fidel Castro has plenty of problems to deal with at home, and it's interesting to wonder how many Cubans would have been denied care had his 1500 doctors come to the United States. In fact, Fidel is fully aware of the political implications; otherwise, he wouldn't have refused most (all?) previous US offers of aid, most recently when Hurricane Denis hit Cuba in July.

And it's not hard to find this stuff out: everything I just mentioned is from articles on the front page (or one link therefrom) on CNN.com.

So, my question is, where do bloggers, currently enrolled at Ivy League universities, get off writing (paraphrasing) about how if even Cuba is offering us help and our government just won't take it, what has the world come to? Is thinking just not in fashion anywhere any more?

Workable

More linkage over yonder; should be decent if the guy updates for more than four updates.

I watched M. Night Shyamalan's movie Unbreakable tonight; I've seen Signs before, and while I haven't seen The Sixth Sense I've heard the plot twist and that somewhat takes away the impetus to see it.

It's become, at least in some circles, vogueish to dislike Shyamalan's movies. The criticisms leveled — that all his movies follow the same basic structure, that he's always working up to some unlikely and heat twisting plot twist, that once you know the plot twist there's not much point in seeing the movie — are all true. And, although I haven't seen his most recent movie, I suspect he may be becoming aware of the extent to which he is recycling ideas. Signs did not feel to me as if it were nearly as meticulously constructed as Unbreakable.

What I noticed, though, was that Shyamalan has a very deliberate, very careful hand behind the camera. His scenes are very carefully placed, and, for an example from Unbreakable, the way in which the Bruce Willis character's security guard uniform transforms into a superhero's costume — without ever actually changing — is masterfully done. To me, it seems rather like Shyamalan's commitment to one story idea is wasting his talent as a filmmaker. Moving away from gimmick filmmaking would allow his real talent, for making movies rather than twists, to show and would alleviate much of the frustration with his movies.

Handbasket, part 2

In the comments to a previous entry, Michael suggested that you might, in fact, get a better preparation to be a software engineer in lower tier schools because, summarizing and giving them the benefit of the doubt, their programs are more likely to focus on methods of development being widely used in the business world at the moment.

On the face of it, this might not seem particularly unreasonable. Currently, a large number of businesses use Microsoft's toolchain, from server-side components written in Visual Basic or Visual C-something (see previous article) to Internet Explorer and ActiveX controls on the client-side. It's reasonable that people more facile with the MS toolchain would be more employable, immediately, than people with the same expertise but in, say, the GNU toolchain, which is virtually unused in most sectors of the American economy.

(Definitions, in the spirit of the last article: a toolchain is a collection of theoretically related tools which, while they don't work with each other in any meaningful sense of the phrase, go out of their way not to work with anything from outside their little club. The GNU toolchain, in this case, refers to a collection of somewhat decent compilers produced by a raving lunatic and his followers. MS is a crippling nerve disease.)

Michael went on to comment on losing your job to Bangladesh within a year, but I think that "within a year" exposes a more significant problem with the style of teaching we're criticizing. I believe that one of the reasons the Microsoft tools are currently so popular is because they come with an enormous library of prebuilt components, functions, procedures, widgets, and so forth. For any given common business task, there is probably a widget somewhere in Microsoft's libraries to solve it; while it's not likely to be the best solution, and probably doesn't exactly fit your problem, it's not hard to add twenty lines of Visual Basic code around it to make it quite close enough, and this means that developing with Microsoft's tools can seem quite efficient.

Unfortunately, my experience suggests that the response to this is to teach computer science/software development/management information systems/whatever at a higher and higher level. Instead of talking about whatever logic underlies Microsoft's libraries, they cover a collection of the tools, standard ways to combine them, and then go on to discuss the waterfall model, and so on. Missing from this picture, though, is a reasonable way to adapt when Microsoft releases the next generation of its tools, about a year from now. Of course, Microsoft's core abstractions and principles don't change drastically from one evolution of their toolchain to the next, but if you don't know any of the core abstractions — if, in fact, you haven't been given the basic knowledge of computer science to understand the core abstractions — then it's not going to make any difference how little they changed because all you'll be able to understand is the surface.

At that point, the case for outsourcing starts to make a lot more sense. If you're going to have to retrain your programmers every two years anyway, why not outsource the whole setup to Bangladesh and save yourself a lot of trouble?

The answer, of course, is that it shouldn't be necessary to completely retrain your programmers every two years. But as long as a lot of universities are teaching a computer science/software development curriculum that goes no deeper than how to align a RadioButtonList with a CheckBoxList and read the Values property of either, Bangladesh looks better and better.

Handbasket model

Several definitions will be necessary for the enjoyment of this post:

IT: Information Technologies. A department/division/branch of a U.S. corporation responsible for accomplishing things with computers and, as I will elaborate, generally failing. Corporations outside the United States probably have IT departments as well, but I don't know anything about them so I'm going to exclude them from discussion right up front.

C: A programming language. C has been said to combine all the power of assembler with all the readability of assembler, but that is not true. C can, in the hands of a skilled practitioner, be either much more readable or much less readable than assembler.

C++: A bizarre combination of punctuation. It is also an enhancement to C in which all the popular ideas between the conception of C and the conception of C++ were crammed into C, leaving a mush. Most significantly, C++ is object-oriented. However, C++ also has a number of other exciting features, such as being able to encode compile-time compilation, objects outside its own type system, etc.

Java: Another object oriented programming language with C-like syntax. It is much cleaner, from a design perspective, than C++ and programs written in Java run correspondingly slower.

C#: The result of Sun telling Microsoft they were taking Java and going home. These days, Microsoft has its own Java.

Visual Basic: a crawling horror. Whereas it is possible, although with varying degrees of difficulty, to write readable code in each of the aforementioned object-oriented languages, we contend that it is, in fact, not possible in Visual Basic. This is an extremely rare accomplishment in programming language design, although it has been accomplished before; see Perl, APL, etc.

Haskell: a functional programming language. Every place that I refer to Haskell in the remainder of this article, you may substitute the functional programming language of your choice. (If you substitute Scheme, you must assume that anything I saw will be "easy" will actually be "moderately difficult." This extends to such things as "tying your shoes.") If you specifically do not prefer any functional language, you may close your web browser at this time and return to hopefully throwing bones at monoliths. You are lost already.

Finally, to truly appreciate this post, you must care about the state of software engineering and IT in the United States. I figure that should weed out the rest of you.

It is a well known fact that for every promise of how information technology

(which is a particularly loathsome term. Book publishing is "information technology." A bullhorn is "information technology." "Technology" is a word which conjures up simultaneous images of ivory towers and pocket protectors and needs to go away completely.)

is going to improve American corporations and the lives of their workers, twenty people wait around for a computer system to come back online, two IT workers curse impotently at the idiotic tasks which fill their days, five office workers play games of solitaire on their computer, and eight factory workers are put out of jobs by robots. To the outside observer (or me) this does not seem like the unqualified improvement that was originally promised.

For every IT-related promise, there is a failure. For every failure, there is an explanation and a promise that things will be better next time. This is known in some circles as a recursive relationship.

I used to believe that this was primarily because most software developers were not trained in software development. Just as chemistry and chemical engineering are difference disciplines, and their practitioners are not considered interchangeable, computer science and software engineering shouldn't be considered the same disciplines. Sadly, at least most places, software engineering is lumped into computer science, taught by (generally uninterested) computer science professors, and it's hard to be tremendously surprised when the graduates of these programs, no matter how personally interested they may have been in software development, are not engineers.

Then I saw a software engineering textbook,

(It is certainly true that there are plenty of lousy textbooks in the world; however, it is my sincere hope that most of them are not used. This book is used at Northern Illinois University which, while it may not be considered at the same level as my particular alma mater in most ranking schemes, does produce ten graduates for every Dartmouth grad and thus probably has a much greater educational impact on most people (and most software engineering projects) than Dartmouth could ever hope to. Following this line of logic, it would seem significantly more important that the quality of education be high at NIU than at Dartmouth, which tends to be the opposite of how it works out.)

and I won't go into details on who wrote this particular book (George M. Marakas) or where you could get more information on said book if you were interested (but here's a start) or whether the author doesn't seem to have noticed any changes in mainstream programming languages since the early 1980s (he devotes one poorly written appendix to a demonstration that he doesn't understand object-oriented design) or changes in mainstream software development techniques since about the same time (he doesn't mention agile programming or any of its variants, and his discussion of rapid application development is anemic) or his tendency to use straw-man arguments (for example, he suggests that rapid application development techniques are inadequate for applications that use cutting edge technology, while proposing a model that takes a minimum of 36 months to produce any results and thus by definition can't use cutting edge anything) or even his inability to produce diagrams that correlate with his text (his discussion of terrariums as closed systems is accompanied by a picture of a tank filled with water and fish) because those are all incidental to whether his core point has any value. It was his core point that crushed all my beliefs about software development education.

I shall summarize his core point as the idea that serious software requires serious design. This is elaborated to the Software Development Life Cycle, or, in more common usage, the Waterfall model. The waterfall model of software development, so called because it consists of a series of stages, and sometimes requires moving from one stage back to a previous stage as a result of newly discovered problem details or research, is a serious design process. Of its seven stages, the first five do not involve writing code or buying hardware. Instead, the first five stages involve discovering problems, researching industry best practices, modeling existing systems, interviewing users and managers about their expectations and experiences with the existing solutions, prioritizing elements of the proposed solution, and performing a variety of other four-syllable tasks. After you have finished all of that up, Marakas seems to claim, you get someone to go write some code and buy some boxen and slap it together and pass maintenance off to someone else, because the important things are done.

I should start out by saying that I fully support, in the abstract, industry best practices, users, models, existing systems, expectations, experiences, and while I have skepticism about managers I suppose I should allow them for the time being. However, I believe his combination of these factors is completely wrong-headed. Primarily, Marakas (and other proponents of the waterfall model, I suspect) ignores all the realities of software. Just as it is not possible to design a building without taking into account the details of the materials you will use, the construction techniques available, the ground it will be built on, etc., it is impossible to prepare a useful analysis or design of a software project without considering the physical and mental resources available and the language and coding techniques that will be used. Most programmers would recognize the ridiculous nature of claiming that a single design document proposes the best solution to a given problem in C, C++, Java and Haskell, but Marakas suggests that the majority of software development should be devoted to producing just such design documents. It is a necessary corollary that design at such a high level cannot produce any sort of verification except at a similarly high level. Unfortunately, such high level verification is completely useless. Observing that a finished inventory system does not produce the right inventory reports does nothing to suggest why it does not or what should be done to fix it, and tests that come from a design that is independent of any particular physical resources or coding techniques cannot be any more specific.

In short, the waterfall model, as Marakas proposes it, is not a model for software development. It might be a management process that could keep managers amused while programmers wrote software, but the more it was allowed to affect the software the worse the resulting product would be. The real tragedy is not, I think, that wrong-headed ideas exist. Wrong-headed ideas are an indispensable part of intellectual progress. The problem is that with stunning evidence to the contrary clearly available, Marakas is touting a phlogiston-based model of software development and that people are listening to him.