Smalltalk Tidbits, Industry Rants

Here's an interesting satire of XP/Agile development. It's funny, but the author makes a simple mistake very early on:

Let's start with what you already know. It doesn't matter if you're building software, a bridge, a space shuttle, or even something as seemingly trivial as a world class meal. The simple principles at the heart of producing any "job well done" are constant. They need not be a mystery to anyone who has ever performed a difficult task from inception to completion, and performed it well.

So this article attempts to have a little fun while exploring what might happen when you apply my vocation's pop project management philosophies to another type of task; bridge building. Perhaps as software developers, we can laugh at our selves a little along the way. What better way to learn?

The problem here is one of assumption - since we know the best practices in some fields of engineering (i.e., bridge building) - then we know that many of these same practices will apply to software development. The assumption is that we know how to plan. And that's a huge - and mistaken - assumption. At this point in time, software simply is not an engineering discipline. Repeat that as many times as is necessary. Software is a craft. As such, one can best compare software development to other crafts - like movie making and putting on a play. Are there 'best practices' that the entire field agrees on?

Heck no. Just as actors differ on how best to prepare for (and practice) a role, software developers differ on how best to develop software. These differences range from the high level methodology that ought to be used (Agile? Waterfall?) to the implementation style (static typing best? dynamic typing best?). People differ on the sorts of languages (imperative/declarative/functional). The point is, there's no general agreement on what 'best practices' for software development are, at any level of the job. Maybe there will be some day - but there isn't now

Which takes us to the parody. The author has decided to define 'agile bridge building', and via that example, poke fun at agile software development. The trouble is, bridge building, for the most part, is a very well understood field. The engineers in that field know what will, and what won't, work. They know what designs are feasible, and what materials are feasible. They know what kinds of trouble are possible given various trade-offs. In software, we simply cannot agree on any of those. Ask two developers, and you'll get three opinions on what is and is not best. You'll get disagreement on how best to proceed, and how best to implement - both at the theoretical and at the practical level.

It's past time for developers to admit the obvious - we don't know nearly as much about this field as we like to pretend we do.

The FTP Server for this system is back online - the IT group has made progress with the new firewall software. Anyone who has had difficulty grabbing the non-commercial download should be able to use FTP now. Sorry for the inconvenience.

This shows that online selling is important - online sales were up 37% this season over last. Looks like I'm not the only one who did most of his shopping in the browser :)

A former Cobalt/Sun employee speaks out on the ways Sun failed after the purchase:

I am more than happy to let you know that the marketing budget set aside for Cobalt in Australia was $0 for the 10 months I was with them. Sun did not understand Cobalt, and tried to mould it into their way of thinking, however we were selling to a different space, and they could never quite fathom that.

A clear marketing failure - company buys a product, has no idea what to do with it, and said product withers and dies. That irritates the customers of that product (possibly poisoning them against considering the buying company's products in the future). It wastes all the resources (monetary and otherwise) spent on the purchase. And it wastes the time spent fumbling the bought entity. I've seen this myself - at ParcPlace, back in the post IPO days, management bought a lot of things - including VSE - which they had no idea how to sell or market. It kind of makes you wonder why they bother - it's known that there's no real plan (at least at some level) - you would think someone would raise the alarm. In many respects, it's a sign that no one is willing to question management, which is a very bad sign - for employees and for management. These kinds of marketing failures tend to get repeated, exhausting resources. What many companies seem to need is a no s*** guy who's willing to ask hard questions....

Squeak has been ported to the S/390 running Linux.

People who didn't already know the LoTR plot

Ok, maybe I'm just naive. There are topics I avoid on this blog - but I can't say that I agonize over the content. Sam Gentile is in a different place:

Which brings me back to the meaning of the blog. The problem with getting very popular in blogland is that there becomes less and less you can say. Every word has to be evaluated on what it might say to people, say to clients of mine, how will it affect relationships, is it meaty enough, and on and on. You end up virtually agonizing over every post and then there are so many things you can't blog on.

I don't know. I guess I can understand the worry, but hey - I write what I write, and it's what I feel like writing. If other people are interested, that's great - but I'm not so worried about this from a popularity contest standpoint. Now admittedly, I'm not an independent consultant - Sam is, and that does impact his choices in ways that don't (at this point, at least) impact me. If people disagree with me - and they do - there are comments and email. I guess I just have to be me :)

Windley points out that the Clark Campaign is embracing open source. Meanwhile, Dave Winer isn't too pleased by this:

Wouldn't it be great if Dean and Clark went after Viacom, ClearChannel and Time-Warner, instead of the tiny companies that make blogging and social networking tools.

I find myself hoping they get their asses kicked, hard. I don't expect much of Bush, but I doubt seriously that he would undermine the mostly American software industry by competing with it with free software. Makes the Dems' pitch about exporting American high-tech jobs to India fairly hollow (NH is a high-tech state, so it has been an issue).

There's some self interest in that, as Userland was originally Dave's company. This is all part of the general push/pull between open source efforts and commercial software. Clearly, a political campaign doesn't want to spend money on technology; like a movie, a campaign is a short-lived business, and it doesn't need to spend money on ancillary things. On the other hand, I can see where companies can get upset over this; we face open source alternatives to Cincom Smalltalk all the time.

Where I part company from Dave on this one is simple - companies like Userland (et. al.) should have considered approaching the various campaigns with free usage in exchange for publicity deals. There wasn't going to be license money from any campaign - but there could easily have been free PR. That in turn could have meant license revenue from others who saw the product being promoted that way. This wasn't a failed business opportunity; it was a missed marketing opportunity

Taegan Goddard (political blog) quotes Dave Winer, who linked to this Scotsman piece. Dave is crossing a lot of boundaries with his blog, and understands something that a lot of the folks over in the Atom crew don't - a good message that can be easily consumed is better than a "perfect" message carried by a "perfect" format...

Scoble thinks he knows why Smart Displays failed - he says it's cost of the display units. Partially, but that's not the major reason - the major reason was client OS licenses. Consider a presumed home user of this:

• Server in the closet
• 4 Smart Displays

Not only do you need to lay out $1K per display, you need to lay out for multiple revs of XP, or figure out how to set up Terminal Services (or Citrix). What you really want is something like X11 (technically speaking). I suppose the biggest issue is Microsoft's business model - their model really, really wants you to buy more clients, and a terminal type usage pattern just doesn't fit that.

Steven Den Beste has written a fascinating article on intelligence - the nature of it, and how it's modified (in people) by certain technological advances. It's a hard article to summarize; there's a lot there. I'd just recommend that you read the whole thing.

What to get for the dead guy who had everything: A glow grave. No need to let death stop your internet access....

FTP access to Cincom Smalltalk is down at the moment; our IT staff is taking advantage of the Christmas/New Years break to upgrade the corporate firewall. As they configure it, various services will be intermittantly unavailable; FTP is off at the moment. Expect things to be back to normal after the turn of the year. Http access is still working.

Slashdot reports that a researcher found post civil war era Smallpox scabs used in live vaccinations. I guess you never know what you'll turn up in old books...

At our recent planning meetings, we talked a fair bit about documentation (both written and online) for Cincom Smalltalk. Here's a link to our current thinking on documentation; please send comments to me

ISerializable links to the Dropload site - sounds like a highly useful service:

Dropload is a place for you to drop your files off and have them picked up by someone else at a later time. Recipients you specify are sent an email with instructions on how to download the file. Files are removed from the system after 48 hours, regardless if they have been picked up or not. Recipients can be anyone with an email address

There have been so many times I could have used such a thing...

So now Beagle 2 is incommunicado. I guess the Martians don't want us to send robots :)

Slashdot reports that the dedicated hacker can redirect the OnStar service to publically available (read, free) services with some effort.

Websites and message boards are rife with step-by-step instructions to personalize OnStar's navigational and communications components. When a driver requests directions from OnStar his GPS data is routed over an analog cellular network to OnStar computers and the directions are read back to the driver on the same network. The price for this service is around $400 each year. Those who tap into their OnStar systems pay no such fees."

Imagine explaining this to grandpa :)

Clarence Westberg thinks that the Web Services game may be bringing the value of Javs down:

"Microsoft couldn't have executed a better divide-and-conquer war plan than the one that's being handed to it on a silver platter." David Berlind writes that in a future dominated by vendor-independent web services standards, the divisive Sun-dominated Java world is a ball and chain around IBM, keeping it from otherwise competing with unencumbered Microsoft. [Source: ZDNet]

His main point is that the spread of web services brings to phones what the spread of web apps was supposed to do on pc's - make the resident OS less important, and the remote one more so. This may play out better on phones than it does on PC's:

For instance, "As cell phones and PDAs become commodities, the value of device-resident software (such as operating systems, games, and other programs that run within the devices) will approach zero. Few people will pay more for a Java-based phone than for one that isn't. But the value of extra-cost and remotely hosted services for those devices will continue to increase. These services include mobile e-commerce (m-commerce), instant messaging (IM), location-based services (LBS) such as advertising-driven restaurant finders, and many others."

If that's the case, then time to market will start to matter more - and anything that allows you to build web services aware applications quickly will be useful. We (Cincom Smalltalk) have already started supporting smaller devices - and we've got good web services support. This may well be an opportunity for non-Java and non-MS solutions to get looked at

The 7.2 based BottomFeeder development stream now supports Atom 0.3. The only real change I had to make was in the handling of the now (needlessly complex) link elements. I think I agree with Dare Obsanjo on this - there's really no value add to Atom format that I can see - it's just another format for us aggregator authors to support, and yet one more choice for end users to have to weed their way through. Meanwhile, some people are ramming that choice down your throat. Here's what Dare has to say:

The fundamental conceit of the ATOM effort is that they think writing specifications is easy. Many of its proponents deride RSS for being ambiguous and not well defined yet they are producing a more complex specification with more significant ambiguities in it than I've seen in RSS. I actually have a mental list of significant issues with ATOM that I haven't even posted yet, the ones I mentioned above were just from glancing at the aforementioned feeds. My day job involves reading or writing specs all day. Most of the specs I read either were produced by the W3C or by folks within Microsoft. Every one of them contains contradictions, ambiguities and lack crucial information for determining in edge cases. Some are better than others but they all are never well-defined enough. Every spec has errata.

The ATOM people seem to think that if a simple spec like RSS can have ambiguities they can fix it with a more complex spec, which anyone who actually does this stuff for a living will tell you just leads to more complex ambiguities to deal with not less.

Higher levels of complexity does not lead to less ambiguity; it leads to more. Why? Well, think of any board games or card games you know - which ones generate rule arguments - the ones with long lists of rules that attempt to cover all possible situations, or the 1-2 page rulebooks that tell you what you need to know? This is why RSS, with it's supposed problems - has few actual problems in the wild. Meanwhile, watch atom feeds that crop up to vary wildly, as different template authors interpret the complex rul structure in subtly different ways. Bah, humbug.

The C2 feed has been repaired. It's been down for awhile; the format of the page on C2 changed, and I hadn't noticed....

Martin Fowler wonders why anemic domain models are so common:

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is very little behavior on these objects. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

Here's the 2 cent answer - most C++ programmers went from C to C++ without ever learning objects. Thus, most C++ objects were glorified structs. Later, most of the Java developers came from the ranks of these warmed over C developers - and again, they didn't pause to learn OO. What you have now is a bunch of Java (and C#) developers who think that anemic objects are objects. There's not a lot you can do about this; these folks don't know what they don't know...

From my daughter:

There's a Multi-Methods implementation in the Public Store. Looks like it was just posted yesterday; check it out - bundle name is MultiMethods. Complete with tests

Scoble is on about Tablet PCs again - and does point out a few lucrative markets for them - hospitals and (large) restaurants. In those spaces, walk around devices likely could be quite big - altough I have some doubts about PC sized devices. I rather suspect that the sweet spot is for much smaller machines that can easily be carried by busy staffers. If you spend hours on your feet, you'll want to stuff the computer in a pocket. Touchpad PDA, yes. Full size, tablet, no. His last idea strikes me as funny though:

Then, take them for a walk down University Ave. Hand them the Tablet PC. Point out that the entire downtown area is a WiFi hotspot. What good is all that wireless unless you can use a computer while standing up? Now, think about all the workers who work while standing up. The teachers. The lawyers. The journalists. The newsbabes on TV.

Personally, I have less than no interest in walking and computing. I want to sit, where I can type, probably with a coffee. Walking around with a full sized screen that won't fit in my pocket sounds awful. I travel with a notebook regularly, and I want no part of that. I suspect that most business travelers are similar; a tablet (so long as it has a keyboard) is a nice to have, not a need to have. WiFi access and a keyboard that doesn't kill the hands and wrists are far, far higher up on the watchlist. I'm going to spend a truly trivial amount of time scribbling anything through a pen (or finger) interface; I'm going to spend scads of time typing. Which means a bad keyboard (hello Dell Latititude) is the thing to watch out for.

Yes, there are plenty of interesting uses for tablets. But in many of the places Scoble thinks will flock to them, I don't see it.

Ted Neward points out some of the reasons why there are performance issues with many EJB applications - it has to do with developers following the rules laid out in the spec in all cases. Ted states that you hav eto know when to vary from the rules, and has this to say on the subject:

To truly criticize the EJB Specification without understanding why they made up those crazy, arcane rules is where the real crime comes in. The architect in Bob's story is committing an evil sin, to be sure, but so are you if you just take away the idea that you never want to use EJB. EJB solves one problem very very well--that of handling distributed transactional processing--in a fashion that's intended to be a very scalable model IF you play by their rules. And let's look at what those rules ultimately leave you with: a collection of objects that don't look like objects at all, but instead look more like a bunch of procedures collected together into lexical scopes (in the case of stateless session beans) or loosely-related objects (in the case of stateful session beans). MDBs fall into the lexical scope scenario, and entities were just a bad idea to begin with, so I'm not even going to consider them. (They should have been something hidden away within the implementation of the session or message bean, rather than something that could be seen outside of the container itself. Much like JDO accessed through a Connector, in fact.)

Basically, the problem comes in when you try to use EJB as distributed object technology. Funny that you might try that with an allegedly OO language :) This ties in with the comments by Anders Hejlsberg I stumbled across the other day - the ones where he states that OO and distribution are at odds with each other. Having looked at the way we do Opentalk in VisualWorks, I don't think that's true. What might well be the case is that OO and static languages attempting to do distributed objects are at odds with each other...

From Fark:

Affleck's character was supposed to be a New York Mets fan, but the 31-year-old actor said he persuaded director John Woo to change the team to the Red Sox.

Still, it could have been worse.

"I would rather say the lines, 'I worship you, Satan,' than say my favorite baseball team is the New York Yankees," he told reporters recently, according to AP Radio.

I have a few words for Affleck:

• Bill Buckner
• Mookie Wilson
• Pedro Martinez, 7th inning, 2003, game 7, ALCS

Heh

In looking over my work on BottomFeeder over the last year, I'm curious about something - what do developers using other languages do about limitations in their base libraries? No base library - not the one in VisualWorks, not the Java libs, not the .NET stuff - is ever without warts, limitations, and bugs. In VisualWorks, I have a number of possible ways to deal with that:

• I can create my own replacement for a library component
• I can override/extend/fix the component with problems

Let me explain what I mean. I use the base VW XML Parser to create documents from RSS feeds, and then use some XML to Object code that Dave Murphy created (and I've extended over time) to create domain objects. The XML parser, as shipped, will throw exceptions on invalid documents. Regardless of how you think XML ought to be, when an end user wants to see content, the fact that the feed is "broken" doesn't matter a whole lot - the software should deal with the problems as best it can. In VW, I can modify the base system libraries (and version my modifications separately) to suit my needs - so instead of bailing on bad documents, the parser instead moseys along. I guess my question is, how do you deal with that in languages where changing the base libraries is not a possibility? And bear in mind, my XML library thing is simply an example - I've done the same thing here and there with other parts of the system.

Do other developers create their own replacement libraries? How do Java and C# developers deal with system libraries that don't suit their needs? I'm curious.

Daniel Steinberg is upset at a comment that responded to this piece on customer/developer interaction:

It is the job of the product manager, business development manager, and marketing manager to make it their business to know what the market wants and to get customer feedback.

If your product does not meet the needs of your market or is not satisfying your customer, you need to point the finger at the Marketing department first. If their research and PRD clearly articulated the market and customer needs, then they are off the hook. Then you have to find out why the development team didn't follow the PRD.

That's the definition of a product company, and it doesn't fully apply to in-house development. On the other hand, if the developers never see a customer, they aren't going to connect that well with the marketplace - take it from a Product Manager - there's no way that marketing, PM, and sales can convey all that meaning down to the developers without some losses in translation. Developers need to have opinions as well, and it's best if they are formed at least in part by interacting with customers.

Bob Westergaard notes that hibernation mode on a laptop is just like a Smalltalk snapshot. Which is why it's amusing to have a developer tell you that images are a bad thing while they snap their laptop shut...

The Anomolistic blog has a nice summary of the first President of the US - no, not Washington - the first President under the Articles of Confederation, the constitution used by the US from 1781 - 1787. There are a lot of good details that most people don't know - the period from 1781 - 1787 is very glossed over in most history classes.

Cook Computing has turned off comments due to the flood of coment spam he's gotten. I've yet to receive any comment spam, and I haven't done a thing to stop it - but I'm not running one of the popular blog servers either. So far, security through obscurity has worked out....

Matt Croydon reports that you can use ssh from your phone to your PC - PuTTY for Symbian. Now, imagine using vi to edit your config files from your cell phone screen....

Another Java developer using (or missing) warmed over C ideas. So much for doing OO...

Michael Lucas-Smith has written a useful utility for detecting a "too deep" stack flow in a VW application.

Two weeks ago, I was clearing snow from my driveway. Tomorrow, I'm off to play golf. The winter weather here in Maryland is just.... bizarre.