Like Chris, I am also way behind on my presentation and a future article, so I am also working today. ...via [Sam Gentile's Blog]

Me, too. And what's the common thread? Presentations and articles. Writing and talking can consume infinite effort; it's something to be cautious about.  At least I got yesterday off.

Martin Fowler argues that even if we abandon Lines-Of-Code, still we CannotMeasureProductivity: "...Even if we did find an accurate way for function points to determine functionality...if I spend a year delivering a 100FP system and Joe spends the same year delivering a 50FP system can we assume that I'm more productive? I would say not. It may be that of my 100FP only a 30 is actually functionality that's useful to my customer, but Joe's is all useful. I would thus argue that while my direct productivity is higher, Joe's true productivity is higher."

I would say that Martin's made a slip, conflating coding productivity with software development productivity. I would say that, yes, the person who codes twice as many function points in a given time is a more productive coder. But the person (or team) that delivers twice as much customer value is a more productive software developer (or team).

Function points are to code what user stories are to software development: atoms of functionality. The fundamental idea of function points is that "Display a button on a form -- okay, that's one atom of functionality. Make a database query -- that's another." And that's how I also think of user stories: "Convert dollars to euros -- okay, that's one atom of client value. Allow the user to choose currencies -- that's another atom." Just as different atoms of client-value (user stories) have different, but short, development times, so too do atoms of functionality. But where the complexity multiplier for user stories is the Planning Game, the complexity multiplier for function points are the complexity matrices of the function-point counting process.

And, I would argue that it's not important that two large-system FP estimates might differ by factors of 3, just as you wouldn't be surprised by differences from XP teams forced to estimate the schedule for a whole deck of user-story cards.

There are lots of lectures going on at Microsoft...many recorded talks online publicly at the Multi-University/Research Lectures project.  via [Curiosity is bliss]

Tell your boss you're watching "PUMA2: Bridging the Processor/Memory Performance Gap through Memory Access Prediction & Speculation " but really watch "The (In)Complete Demystification of Chocolate."

On the one hand: "...what coder is slinging 100 lines of code a day? That's an exceptionally GREAT day of coding... " and on the other, "Strong typing is one reason that languages like C++ and Java require more finger typing..."

There's a lot of froth right now that claims that implicit typing is an important contributor to programmer productivity. The all-industries average productivity in software development is 1,500 debugged lines of source code per month -- call it 75 lines per day. Also, it's long been said that the number of lines per code written per month is pretty much independent of the language used; it varies greatly per individual, but the same programmer reasonably versed in Python and COBOL will write about the same amount of lines per month.

The corollary in language design is that you want to maximize the amount of expressiveness per line of code written. It takes fewer lines to express a text-matching-and-replacement intent in Python than it is in COBOL, so it's legitimate to say that Python is more productive for that kind of work than COBOL. Similarly, a spreadsheet is more productive than Python for, say, expressing a variable rate mortgage calculation.

But the point is that finger typing on a given line is a small contributor to productivity, everything else being equal. I've spent the past month working in Visual Basic .NET, in which I can write:

dim x = y

or

dim x as Type = y

It's my thesis that the 8 extra keystrokes in the second form are less-than-trivial in terms of mental and physical effort and have major benefits. The first form is not easier to conceive -- I clearly have an intention relating to the type of x when I write the first form, it's just a matter of making it explicit or not. But by making it explicit, I aid in comprehensibility, maintainability, and tool support. I'm not aware of any implicitly typed languages whose editors perform on-the-fly type inference and provide features such as code and parameter completion.

It seems incontrovertible to me that on-the-fly lists of available methods and properties provide more of a programmer boost than is lost by explicit typing. For one thing, explicit typing is only required for declaration, but on-the-fly type-support is available for wherever the variable is in scope. For another, whatever mental burden is required to explicitly state one's intent as to type is undeniably trivial compared to the mental burden of remembering the precise form of a type's operations.

And don't try to argue that editor support "is not part of the language and therefore is irrelevant." Your interaction with the editor is a language; one in which you express the programming language. Just because there's sometimes close to a 1-to-1 correspondence between the pressing of keyboard keys and code characters, you can't ignore the fact that the languages of editors differ in how tersely you can accomplish certain goals. With on-the-fly type support, for instance, I can express the intent to retrieve the value of x's PropertyWithALongName with, perhaps,

x.P[Tab][space]

rather than

x.PropertyWithALongName[space]

And those savings in "finger typing" are at least as valid as the savings from implicit typing.

I say "implicit, schmimplicit." Until design-time type-inferencing editors become available, be explicit.

Ingo criticizes the use of airline reservation systems as an example in distributed concurrent systems: "The last time I checked, a ticket was no guarantee for a seat and the only real transactional guarantee for a seat is during check in. Reservation doesn't count too much here."

Since I've spent most of this millennium  programming airline reservation systems,  I can comment. The reason that such a system may not be a good example for distributed objects is not ticketing, but the fact that all Global Distribution Systems (Sabre, Apollo, etc.) reflect 40 years of cruft. Sabre, once the "Semi-Automatic Business Research Environment," was the first large commercial distributed system; a true pioneer in the history of computing. Here's an example: a fundamental assumption of GDS's is that seats between any two city-pairs are rare on any given day, even say, between New York and Washington. And availability is not an accurate empty-seat count, but a series of fare classes and a number between 0 and 7! (Why 7? Because 3 bits rather than 4 saved real money in 1962. [Apparently Galileo goes to 9 -- ed.]) And lots of crucial data, like fare-change rules, are never implemented according to whatever standard was cooked up in the 70s, they're almost always implemented in "comments" fields in an organization-specific way that's evolved for decades.

But the real lesson to be learned from programming reservation systems is how you must place the client above your textbook learning. If you went to an airline or a travel agency and said "No, a Flight should be this, a TravelParty should be that, and an Itinerary should be this other thing," you'd never be asked to even bid. Instead, you have to appreciate that the greatest concern of such clients, far more than improving efficiency, is losing efficiency for any amount of time. If you said "There's a 90% chance of a 20% permanent improvement in efficiency, but it'll cost you 10% efficiency loss for 1 month," they'd show you the door every time, because such organizations are so attrited (especially from the past two years), they have no margin of error.

So what you do when you're programming an airline reservation system is make everything subservient to the customer's existing processes, both automated and manual. Your job is not to enlighten these people about the world of objects; your job is to create a system that is as invisible as it can be.

Having said all that, it's really cool when, having implemented an Open Travel Alliance-compliant XML front-end to a system, you can prototype all kinds of smart clients and smart searches.

Will you vote for my proposed BOF gathering at PDC? It's on page 4.

"C#'s super and VB.NET's invaluable, but it's been argued that the greatest benefit of .NET is the level field it provides for programming languages both familiar and exotic. This session will bring together language enthusiasts and implementors in a casual atmosphere to discuss and demonstrate both existing languages and works-in-progress. Does the runtime help or hinder particular programming types? Is anyone using alternate languages in production? And is it possible for us to perform an impromptu interop-a-thon: F# -> Eiffel -> Haskell -> Python -> Fortran -> Smalltalk -> ... ?"

A student who wrote a violent short story on a school computer may face 10 years in prison. Prosecutors say they are trying to prevent more school massacres; the student's defenders say they're fighting attempts to criminalize thought. By Kim Zetter. via [Wired News]

Boy, am I lucky that this sort of paranoia about "dark thoughts" wasn't around when I was in school. I mean, being moody and pissed-off seems fairly central to the teenage experience. What, do they think it's better for the kid to "push your bad thoughts down, down, down into your shoes, until it's like you're walking on them"?

Also in EWeek, Spencer the Kat reports that at at a recent conference, during his keynote Don Box spotted Miguel de Icaza and called "Miguel, I brought an employment application. Your ass is mine!" Do you think Jack Messman laughed or blanched when he heard?

EWeek reports that IT workloads are rising and the cause is an increase in new projects and not so much from layoffs. This from a survey of 1,400 CIOs by Robert Half Technology. But about 2 pages later, they have articles that convincingly forecast flat IT budgets for 2004. To me that spells tech projects moving off shore even faster than the rate we're currently witnessing. Maybe it's time for Ed Yourdon to write another book: "The Undercutting & Bankruptcy of the American Programmer."

Somewhat disappointed by last night's Marin premiere of "Step Into Liquid," the surfing documentary whose original trailer was just about the best 5 minute film I've ever seen. The highlight of the trailer was a sequence in which the basso profoundo announcer says "And including..." (sea begins to rise) "...the much anticipated footage from..." (ocean is now a vertical wall) "... the Cortes Bank." (fly speck surfer drops in to the opening chords of The Butthole Surfers' "They Came In," followed by 30 seconds of absolutely insane big wave surfing). But it turns out that sequence was edited from sequences throughout the movie. The truth is, the climactic Cortes Bank sequence is pretty much a bust visually, as they never get the cameras in position to shoot the wave face. It's epic surfing, with a 66 footer, but honestly, the best filming in the movie is from good ol' Hawaii, where they have helicopters and swimmers and shore-based telephotos. And the narration is cheesy. AND to top it all off, the Cortes Bank session is set to a The Sheila Divine song, not the perfect-for-an-action-sequence "They Came In."

But still, it's probably the best action movie of the Summer.

The August CACM contains an article "Understanding email interaction increase organizational productivity" (not online) which finds that it takes about a minute to resume work after being interrupted by an email notification. Which is kind of problematic if you set your email to check for new mail every five minutes! So I've set my email checking to once every 45 minutes and, even more importantly, I've slowed down my news aggregator to... once every six hours. I don't know if I can handle the information isolation, but I'm going to give it a shot.

I'm skeptical about J#. via [Eric.Weblog()]

I'm not. As I say in the current SD Times, the thing about J# is that it serves two very real niches: the bet-hedgers and the Java "pragmatic believers." Bet-hedgers are those people who have decided not to jump to .NET, but who wish to keep their options open in case the market suddenly shift or if a particular opportunity arises. For those people, the key is maximizing their understanding of the .NET Framework per minute spent and even though it's only a matter of days for a Java programmer to learn C#, it's a better option for those people not to learn anything about languages, and just maintain a "bet hedging" knowledge of .NET.

When I say "pragmatic believers" I'm referring to those who fall short of reflexive loathing of all things Redmondian, but who believe that particular Java language features (say, checked exceptions) are important. Those people might eventually move towards a non-Java language, but if it's not a great burden on MS to support them, why force them to make a decision?

The big challenge is that as the Java language evolves, how much effort will Redmond expend to keep J# in synchrony? Many of the features in the upcoming "Tiger" release of Java are already in C#, so those will be easy. The big question is generics -- both C# "Whidbey" and Java "Tiger" will have a C++-derived syntax for generics (Collection<Type>), but early indications are that the underlying implementations will be hugely different. Given how ubiquitous generics will become the instant they become available, this may very well be the spot where J# and Java become eternally incompatible.

I've made a concerted effort to try programming in my "off hours" on the Tablet PC...in slate mode...without a keyboard...or external monitor. (Yeah, sounds crazy, but I really wanted to understand what it's like.) How's it going? It's passable. via
[Incremental Blogger]

 

F'ing A -- I've begun receiving bounced email messages indicating that someone's using my email address in the "From:" line of I-Worm.Sobig.f spams; you know, the one that says "re: Your application" and stuff like that. Is there any protocol for me sending out "No, no, that's not me" emails or is it just something that I ignore?

As I'd been hoping, Brad Abrams confirms that the gimmes at this year's PDC will include:

- Longhorn (Windows v.Next)
- Whidbey (Visual Studio v.Next)
- Yukon (SQL Server v.Next)

I would've been pretty angry if we'd spent $1700 to go learn about these things, and then not been able to use it afterward. :) Clearly, this is the must-attend event for Windows developers interested in the future (uh oh, what happens when you start to sound like Scoble? :-p). via

[The .NET Guy]

 

Well, that's one way to lose 6 pounds in 3 days... I went diving on the 1st and by Wednesday I realized I had an ear infection. Went to the Doctor and got drops. No biggy. And then Thursday, it was like my head exploded: both ears swelled entirely shut, stabbing pains throughout my head (lots of nerves in the ear... oh yeah!), and my temperature went over 102! For the next 48 hours I would sleep for an hour and then be awake for a half an hour of pain and then fade into sleep again. It was wild; I didn't know ear infections could be like that. I still can barely hear, but the fever's broken and I can eat again. Oh, and yes, of course, this was on the eve of the end of a project for a first-time client: "Uh, I have to call in sick today..."

The good news is that when I was lying in a stupor the FedEx guy dropped off my copy of Borland's C# Builder. That I haven't installed it yet is proof enough that I was really, really sick. Stay tuned for reactions in the coming days...

McDonald's is testing new gear that eliminates human burger-flippers for robotic fridge-to-grill systems. via Link
[Boing Boing Blog]

Okay, if even burger flippers are going to be joining the unemployment roles due to productivity gains, what's so unthinkable about European-style work hours and vacations?

Bad software.  It’s everywhere.  I know a guy who stinks as a programmer.  He makes about 60k a year, and at least ¼ of his time is spent maintaining a particular pile of crap program that he birthed into this world 5 years ago.  He’s constantly welding more junk on to get it to do the latest thing that his company “needs”.  The thing is a complete monstrosity.  How it hasn’t collapsed under its own weight is a miracle. And if the guy ever leaves, it will probably take a new developer a good 3 months of doing nothing else, just to figure out the basics of this (shudder) application.  There’s no documentation, no source control, hell, where there are comments they’re really just disinformation at this point.

 

Chris Coulter proclaims August 19th to be The International Tablet PC Meetup Day. Pick a meeting place in your area and spread the word....
[Incremental Blogger]

AT&T GSM(TM)/GPRS General Discussion: NEW BIG GSM National Coverage Map
[Brian Jepson's Weblog ]