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.
Archive for August 2003
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.
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
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,
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”?
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.