Saw this on a Slashdot thread about how "software engineering" is not really engineering, and how if software emulated "real" engineering it would be better. This guy (girl) made the point that for construction, it's just as bad as for software.

Re: For the life of me (Score:5, Insightful)
by Linux Ate My Dog! (224079)on 2003.02.18 8:17 (#5326407)
(http://exonome.com/fj/)

Why not try to take a look at some of the long time methods used by engineering industries to see how they go about designing bridges and cars and stuff like?

I live in Boston, home of the Big Dig. Right now is not the best time to impress me with construction as a model for controllable effective on-time on-budget engineering of large-scale projects.

In fact, we get to hear this a lot as software engineers "Look at construction! They got it right!" Well, of all big construction projects I remember (Betuwe tunnels in the Netherlands, Stopera in Amsterdam, Big Dig in Boston) went into time and costs overruns, often by 100 to 400% on either variable.

And then there is my bathroom which I had remodeled a year ago, and the stories of my homeowner friends who did the same. On time? On budget? Don't make me laugh. Go do the rounds among people who have had remodeling done: horror story after horror story. Construction people were like software engineers in the dot-com boom: flooded with offers, so they would overbook and the customer who complained loudest would get his project done. Many sub-teams (projects, tilers) did and do not communicate, project leads are at the mercy of the scheduling of the sub-contractors, the quality is not standardized at all but incredibly variable so you have to get "lucky" with who has a slot free to do the work on your project, many of the people are overworked or "self-medicated" to deal with their stress and the conditions of labor.

I bought the whole "Look at construction!" mantra, and then I actually looked at how construction was done. These guys wing it as much as we do for the small projects, and when they can't wing it for the big ones, major shit happens like on our projects. And the old COBOL software is still running after 40 years and will keep running as long as the environment doesn't change, just like bridges stay up for decades as long as the environment doesn't radically change.

Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?

Actually, yes, these people are constantly re-evaluating their process because their time-to-market requirements are constantly getting tighter and tighter. Just read Business Week for six months and follow the changes in the auto industry through their articles: they are all about faster, faster, and listen-to-the-customer constant process-reengineering, with CEO and design heads being hired and fired depending on how well they can make their human- and machine-assembly-lines line up and fire.

Interesting if you have to deal with Unicode.

http://www.jbrowse.com/text/unicode.html

It's high-level enough that you don't have to be a programmer to understand the issues. I like the definitions for "character", "encoding", and "glyph".

I had to laugh at this spam I received.

To: "$user" <$user@netjeff.com>
Subject: FREE offer for $user
From: "" <>
Date: Mon, 23 Dec 2002 16:24:01 +0-200

Clearly their "spam-send" tool needs a little work on the $user thing. :-)

http://softwaredev.earthweb.com/sdtech/article/0,,12065_988641,00.html
By Charles Connell
Everyone wants programmers to be productive. Managers of programmers want maximum productivity — it gets the work done faster and makes the managers look good. All other things being equal, programmers like being productive. They can get home earlier, reduce stress during the workday, and feel better about their finished products. Programming productivity is even in each country's national interest, since it advances the country's position in the worldwide software industry.

Unfortunately, the standard definitions of software productivity are incorrect. They miss the essence of software development. This article examines some of the usual definitions for programmer productivity, shows why they are wrong, and then proposes an alternate definition that accurately captures what programming is really about.

Read More …

"We reject kings, presidents, and voting. We believe in rough consensus and running code."

— attributed to Dave Clark regarding software design

A recent article devoted to the macho side of programming made the bald and unvarnished statement:

Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

Read More …

JavaWorld has a nice summary of Aspect Oriented Programming(AOP). This is the first part of a series that will focus on AspectJ, a Java implementation of AOP. But the first article is mostly language neutral.

Geeky sig on a post by slashdot reader Jon Abbot (but it made me laugh)…

A bash poem:

time for echo in canyon; do echo $echo $echo; done