Software in a Blink

Software can be Blinked too.

Blink: Malcolm Gladwell’s book about the underestimated importance of intuition and first appearances relative to rational analysis and decision-making. Hugely successful in the blogosphere (relevant there too) and slammed on yesterday’s Slashdot Review for essentially being blatantly obvious. I’ve just begun to read it this week.

As a developer with a big usability bias, I treat software quality – particularly maintainability – as an exercise in user-centered design. If I was designing controls for a plane, I’d want them to be intuitive, so the pilot could get a feel for the overall layout in a blink. And just the same for software. I want someone to glance at a design diagram and get a feel for the overall architecture. I want someone to look at a class outline and get a feel for the class’s responsibilities and workings. And I want someone to look at a screen of text and get a feel for what’s going on and how the control is flowing.

Yes, software may be complex and the devil is often in the detail. However, ** first impressions count. They shape the way everything is subsequently processed, and can rapidly boost or hamper further learning.** A mere few seconds should be enough for a meaningful introduction to a module at any level of abstraction, from high-level architecure down to individual code block.

Movie Reviews: The Google Semantic Web

Google’s Movie portal is an early version of an application area which will expand rapidly in the next few years: portals which extract meaning from the web.

I’m going to be the 2000th blogger today to mention a new Google feature. This time, the “movie:” search which links to a bunch of movie reviews.

This is less about movies and more about the semantic web. Listen to Bill Gross in a recent IT Conversations podcast talk about Snap’s features and you’ll realise there’s a lot more that can be done to basic search. For instance, here’s Snap’s MP3 Players Search Results. There is a nice comparison table which has (apparently) been automatically extracted from the web at large.

I expect this is where google wants to head. Go beyond relevance-based text search and extract out the meaning from all these websites into a useful portal of information. Movies for now, but could be cars or houses in a year’s time. Many comparison shopping sites have tried to do this, but it never quite works and is easily gamed. Google knows how to present data cleanly and has plenty of experience in not being gamed.

Clay Shirkey wrote some time ago about the semantic web, arguing that sophisticated protocols, well, won’t really do very much. There is a good argument that the information will work fine in fairly free form, with intelligent systems like Google able to piece together some meaning. A memorable quote from Clay’s article:

Dodgson’s syllogisms actually demonstrate the limitations of the form, a pattern that could be called “proof of no concept”, where the absurdity of an illustrative example undermines the point being made. So it is with the Semantic Web. Consider the following, from the W3C’s own site:
Q: How do you buy a book over the Semantic Web?
A: You browse/query until you find a suitable offer to sell the book you want. You add information to the Semantic Web saying that you accept the offer and giving details (your name, shipping address, credit card information, etc). Of course you add it (1) with access control so only you and seller can see it, and (2) you store it in a place where the seller can easily get it, perhaps the seller’s own server, (3) you notify the seller about it. You wait or query for confirmation that the seller has received your acceptance, and perhaps (later) for shipping information, etc. []

One doubts Jeff Bezos is losing sleep.

3 points, Shirky.

String, CharSequence, and the curious naming of length()

Simon Harris (chapeau Dion) discusses CharSequence, the interface String and StringBuffer decided to conform to since J2SE 1.4. CharSequence gives you an okay interface with which to enjoy the goodness of mock onjects and the like. However, it’s nothing to rave about as it lacks most of the methods in String, and as Simon points out, it’s mutable where String is not. A MutableCharSequence sub-interface would be a nice contribution.

In any event, CharSequence is unfortunately not a lot of use for one simple reason: it is largely unknown. APIs almost exclusively rely on String rather than CharSequence, so you’d have to continually “(String) seq” downcast or “toString()” convert to interact with any libraries, including the Java API.

While we’re on the topic of String, how about a “getLength()” method aliased to the unfortunately named “length()”? It wouldn’t be a true Javabean property due to the lack of a “setLength()” method, but good enough for most bean-based frameworks to read it as a property. In particular, JSPs would be easier if you could do a getProperty or a $s.length in JSTL. (And I could say similar things about Collection.size().)

Try To Not Be Dell

I just caught Des Paroz, Acer Australia CTO, on a recent G’day World podcast. Overall, it gives a good insight into the issues a large vendor like Acer deals with.

They touched on Dell (37:30 in).

Cameron: The big … E-Business case study for the last 5 or 6 years has always been Dell and their whole just-in-time model … Is (Dell) still seen as being the epitome of just-in-time supply chain engineering, or has the rest of the market caught up?

Des: First of all, Dell are innovators in … what they do … I think one of the things we try to do is to not be Dell …

Some good points here. Firstly, every generation seems to have its heroic companies, and there will be plenty of MBA graduates immersed in The Way Of Dell. Insofaras their business model and its execution packs a lot of lessons, that’s a good thing. And I’m not going to bemoan its existence, because it has done a lot to drop costs, keep the specs flying alone, and prove the power of IT when applied judiciously and comprehensively throughout an organisation.

It’s likely, though, that many companies will be hurt trying to imitate Dell’s strategy too closely. Its model may not require industry dominance of monopolistic proportions, but it does rely on huge economies of scale. Furthermore, there are huge markets they can’t cater for. Just about every Apple user, for starters. Those are people for whom the 25% off doesn’t mean very much. And, on a personal note, there are those who revere support, and realise that, for all its Fortune 500 prestige, Dell can’t help individuals, and, I suspect, small businesses. Having spent too much time on the other end of “support” calls to Dell’s offshore centre, I rest my case.

Of course, who cares? Dell probably doesn’t – it’s doing fine across the board. The companies that must care are those like Acer. And, those in other industries, where there will no doubt be more and more companies aiming to be The Dell (or The Walmart) of fruit-juice/lawnmowers/hairdressing salons. As the race to be The Dell continues, it will serve many companies well to do as Acer does, and strive to Not Be Dell.

TechPodcasts Aggregator Feed

Did you know that Todd from GeekNewsCentral has been running a Tech Podcasts alliance for a while now? I posted his open announcement a while ago, signed up, and since then, the site has been evolving.

There is now an aggregated podcast feed page: I understand a corresponding RSS feed is on its way.

Anyway, tech podcasts have truly arrived, for this is the week when they were first biled.

O’Reilly Head First Series: +1 Interesting

Dion asks “What do you think of the O’Reilly Head First series?”

In a word, brilliant. I scanned through Head First EJB about a year ago and was extremely impressed by their fresh approach. They categorically state there will be plenty of redundancy, and redundancy is exactly what people need to learn tough concepts. So, within a chapter on a particular topic, they’ll jump between various formats – normal prose, Q&A, diagrams, stories. And the best format of all: cartoons showing EJBs chatting, and sometimes arguing, with each other (a little like this TSS cartoon, Dion).

People like to anthropomorphise technical components, so it can be a very powerful learning tool to show EJBs arguing about who does what. The redundancy is the key here: combine such evocative imagery with more detailed tech talk, and you have a format that keeps readers motivated and answers many more questions than a standard prose form would.

I’ve tried to do something similar to this with the Metaphors for the Gang Of Four Design Patterns. It’s a completely different way to describe patterns, and I think that people can learn patterns best by seeing how they apply in as many contexts as possible.

Naming Conventions for Key-Value Maps

How do you name Maps? Maps of the key-value pair variety rather than the hip Google-enabled map of the USA.

There seems to be no convention. Even for individual programming languages, there seems to be no convention enshrined in the culture, although some languages naturally favour shorter names than others.

Let’s say I’m mapping each captain to their respective team. There are several naming strategies:

  • values as in teams. Succinct, but doesn’t tell you what the keys represent. It’s usually not apparent from the declaration (e.g. Map) or initialisation (e.g. new HashMap()), so you’d have to go and find code that uses it or read a comment. So it would be a particularly choice if used as a parameter for a published API.
  • mapFromKeysToValues as in mapFromCaptainsToTeams. Says it all, if a bit verbose.
  • mapOfKeysToValues as in mapOfCaptainsToTeams. Ditto.
  • keysToValues as in captainsToTeams. More succinct, but the shorthand form belies that its a noun. So someone reading “print(captainsToTeams)” will probably interpret it as “print the map of captains to teams”. I’d rather the structure be more clear at a glance.

I used “keyToValues” for a long time, but I’ve recently switched to this:

  • valuesByKeys as in teamsByCaptains. If you’re going to include both key and value, this seems to read best. At a high level, you can read it as just “teams”, so anything that’s performed on it is being performed on teams. The “…byCaptains” prefix reads as it should do: a less significant qualifier that follows the teams around to help someone understand the structure if they need to.

In all cases, I’ve assumed plural. There’s certainly an argument to be made for singular form, as in captainToTeam, or any combination. I find plural works best in most contexts.

With template-style structures such as Java 1.5 offers, values might be the way to go. With a name like teams, you can’t immediately tell the key type, but you can always locate the type in the declaration. That’s different to the pre-1.5 situation, and dynamic languages, where you have to locate actual code. With the key type being part of the map type, simply values is probably the right trade-off. Unless the key type tells you little about the meaning of the key, such as String, in which case I’m still running with keysToValues.

Calculator Buttons Are So Retro

And while I’m on calculators, Chris Stevenson has been writing about the inconsistencies of calculators. The inconsistency in different PC-based calculators is interesting, but I find it even more interesting that all these calculators exist at all. They are 1975 devices simulated in their 2-dimensional glory on 2005 monitors.

I assume the main reason they are still used is familiarity, availability (every new GUI comes with one) and lack of any well-known substitutes. Still, the idea of mouse-clicking on buttons appeals about as much as trying to turn a dial on a funky skinz-based MP3 player. You can use a keyboard too, but then why show the numeric buttons at all? I’d rather use a text-based interface like google, where you can easily backtrack and clear up any ambiguity with

Of course, a small enhancement would be to make it dynamic, so you can see the current result as you type. It could even be done over the web, via Javascript or some intelligent networking as demonstrated by Google Suggest.

Actually, a “calculator” would be nice in a desktop toolbar. Type the problem in the textbox, see the answer beside it. It would need some way to pop up for longer queries (TSR’s coming back, baby!), but would work quite nicely in the typical case. That would work for other queries too.

Google Calculator: Sign Of Things to Come?

Russel Beattie points to the emergence of ubiquitous search and asks if it’s a trend towards the AI dream of asking the computer any question you like. It’s a powerful idea and it would seem to be the way google has generally been heading … for instance:

I guess Ask Jeeves also had this idea, but never (yet) really carried it out. Given enough computational power, there is a lot more search engines could do to interpret what sort of information is being sought. An IT Conversations podcast a couple of months ago had the founder of Snap explaining how you could search for a product like “Digital Camera” and receive a table comparing product specs.

Java The Dynamic

Java can be dynamic too. Somewhat, anyway. Some blogs have recently looked at static versus dynamic mindsets, and it’s all part of a mindset dichotomy throughout the industry.

Bruce Eckel recently noted that Java is evolving towards semi-static, semi-dynamic :

Java attempts to straddle the gap between statically-typed languages like C++ and dynamic languages like Python, Smalltalk, Ruby, etc. In fact, I think that Java’s biggest contribution may be as a bridge to dynamic languages, just like C++’s contribution was a bridge from procedural to OO.

While most of Bruce’s argument is based on the new features of J2SE5, it could also be based on older features too. Reflection, dynamic proxies, and byte-code manipulation have paved the way for dynamicish frameworks like JMock and the various AOP offerings.

A few days later, Bill Venners wrote something rather complementary to that post. In “Static Versus Dynamic Attitude”, he outlines a design dilemma: essentially, how to represent a bunch of attributes … as a Javabean or as a Map. This is a problem which often arises in multi-tiered architectures, because it is usually necessary to pass a cluster of data between layers. For instance, passing a Value Object from an EJB to a Struts action, or passing a result set from a Data Access Object to an EJB.

Well, the answer firmly depends on your mindset. If you’re statically inclined, there’s no two ways about it: the Javabean will give you the benefits of type-checking and name-checking. If you’re dynamic, you’ll fall for the Map every time: why waste time adding behaviour-less POJOs that clutter to the code base, when realistically, you’ll probably get the name and type right anyway. Even if you do err, you’ll find any runtime errors soon enough anyway. The usual Java way would be static, but the point of this article is to question that logic: ** why should the dynamic arguments apply to a Python program, but cease to apply to a Java program?**

At one level, this is the Sapir-Whorf Hypothesis applied to Java. The Sapir-Whorf Hypothesis says that people think according to the language(s) they speak. It’s certainly relevant to programming languages — there’s even a Wikipedia entry on that topic.

However, it’s more than just language. It’s culture. Mainstream software development has two threads running through it. One group takes a risk-averse view and likes well-defined contracts, checking with compilation and grammars. The other group is willing to add a degree of risk to cut this overhead. It’s Hani’s Good Versus Evil. It’s Adam Bosworth’s “two diametrically opposed tendencies”:

On the one hand we have RSS 2.0 or Atom … On the other hand we have the world of SOAP and WSDL and XML SCHEMA and WS_ROUTING and WS_POLICY and WS_SECURITY and WS_EVENTING and WS_ADDRESSING and WS_RELIABLEMESSAGING and attempts to formalize rich conversation models … On the one hand we have Blogs and Photo Albums and Event Schedules and Favorites and Ratings and News Feeds. On the other we have CRM and ERP and BPO and all sorts of enterprise oriented 3 letter acronyms.

So should you use a dynamic solution in an environment where the mindset is static. Of course, if it’s the best solution. It comes down to pragmatism, and that’s not a cop-out, because the only way to make a pragmatic decision is to make the effort to inform oneself of all the options. As Bruce Eckel’s followup post points out, “if I learn a new language that has a different way of thinking, then I can go back to a previous language and apply that way of thinking”.