kontrawize

I'm mobile, not connected

Another article at The Register notes that it is notebook sales that are keeping the PC market afloat. So more and more of us are using notebook computers. A lot of these are now equipped with wireless networking hardware, which is great when you are travelling and need to use the Internet. Also great when you want to write a blog entry in an arbitrary room in the house.

But, and here's the rub, I'm not always connected. I'm not always in range of a wireless network. So it's annoying when I find software whose only documentation is on the Web, and not in a form you can download. Is that really so much to ask?

There are a lot of client-server applications out there that don't allow the client to run when disconnected from the network. They are easier to write that way, but they don't suit notebook users. With notebook sales becoming so dominant, I wonder if this will change. I hope so.

Too much shrapnel in your pocket?

According to The Register, a third of Brits would like to have a 99 pence coin (100 pence to the pound) to avoid picking up loose change every time they buy something that costs £***.99. Well, based on a sample of 1 250 people, anyway.

They reckon £133 million per year (US$240 million) is lost each year from people throwing away this loose change. If we assume this is all 1 penny coins, that means 13.3 billion coins per year, i.e. two pennies for every man, woman, and child on the planet. It's a great story, but that can't be right. Can it?

Media training for Muslim leaders

The ABC (Australian Broadcasting Corporation) reports that the Australian government is recommending media training for Muslim leaders in Australia. The issue is to make sure that the Muslim leaders are clearly able to articulate their ideas and issues without being misrepresented by the press.

Given the sad divisions that have appeared recently between Muslims and non-Muslims, I think this is to be applauded. We have nothing to lose from understanding each other better.

No best practices

Sometimes you read something, and you think "yes, yes, yes, absolutely, yes". I felt that way when I read this blog post from James Bach, via a thread on the TheServerSide.com. This is a comment I've made myself to people, that everybody wants to be implementing industry best practices, but we usually don't know what they are yet. If two people are thinking the same thing, then I usually find that anywhere between 200 and 20k people are thinking the same thing. So I think a lot of people are feeling this way right now.

They used to say that nobody ever got fired for buying IBM. Those days are gone, but it seems like the new replacement is nobody ever got fired for implementing industry best practices. It's either that or nobody ever got fired for using Apache software.

Actually, where I usually hear the phrase industry best practices is in meetings. If somebody wants to block your technical proposal, they'll say "Is that industry best practice?" Since nobody really knows what the best practices are, it's a question that can be a bit of a killer.

James Bach nails it in his blog. There aren't so many broadly applicable industry best practices (IBPs) in software, but there are some good practices that apply in certain contexts. The trick is to understand which contexts, and whether they apply to your current project. I've seen architectural proposals that are filled with IBPs, but with little consideration for whether a grab bag of IBPs really constitutes the best and most coherent solution to the problem at hand. Just because some software tool or technique is flavour of the month (FOTM) doesn't mean it's an IBP. People seem to miss this difference.

Let's make a stand now for appropriate practices, and leave IBPs for vendor marketing blurb.

Decoupling with interfaces and XML

A well known technique for allowing software interfaces to change over time (and XML schemas similarly) is stagger the addition of new methods, and the deletion of old methods (for XML, replace methods with elements/attributes). If you want to change a method, you have to create a new one first, announce the deprecation of the old method, and then delete the old method sometime later, hopefully after you have checked that your users have migrated to using the new method.

It's a well proven technique, but the curious thing is that people don't use it as much for their internal company interfaces, as opposed to their external interfaces (i.e. those used by the outside world). For internal development, many developers are pushed into making sudden changes to interfaces, even if it impacts other internal development teams. When you suddenly delete an old method, you force other teams to migrate immediately, and that forces the teams to align their release schedules. Whenever you have to align every team's release schedule, you lose time and money as some teams have to wait for others.

So why do companies do it? There is some cost to maintaining both the old and new methods together for the interim period. That seems to be enough to convince managers that a quick, harsh change is better. It can be a false economy, especially as the number of teams increases. So be careful about this one.

Get your shorts off

Off Amazon, that is. According to The Register, Amazon are planning to sell short stories and chapters of books for US$0.49 each. It sounds like a great idea for short stories. However, I can't see myself paying for a single chapter of a book. That would be too much like paying for an advertisement for the book. Short stories are cool, though.

Gratuitous precision - it's a problem!

I studied physics at university. In scientific measurements, there are two very important concepts: accuracy and precision. Accuracy is how near or far you are from the "correct" value. Precision, on the other hand, is about the number of significant digits or decimal places in a numeric value.

For example, if you ask me my height or weight, the numbers I give you won't be exactly correct. Whether or not they are accurate (though I don't usually lie about my weight), the precision is likely to be plus or minus 1-2 cm (0.4-0.8 inch) for my height, and plus or minus 1-2 kg (2.2-4.4 lb) for my weight. When you ask someone their height, you don't expect the precision to be as bad as plus or minus 1 metre (3 feet 3 inches). Nor do you expect the precision to be as good as 1 micrometre (1/25400 of an inch). So nobody writes their height as 180.3141592653589 cm, because that's just a stupid level of precision.

However, because calculators and computers can handle lots of decimal places, and hence very precise numeric values, people sometimes fall into the trap of gratuitous precision - quoting numeric values to too many digits. The problem with doing this is simply that it can give quite the wrong impression about a value.

In the Java programming language, date/time values are represented by the number of milliseconds before or after the start of 1970. This is standard approach for representing time on computers, it isn't unique to Java. The problem with this way of representing dates/times is that it lets you represent a point in time accurately, but doesn't tell you anything about the precision.

If I tell you that I will meet you at the pub at 7pm, you won't be surprised if I walk in at 6:55pm or 7:05pm. However, if a computer program encounters the time 7pm, that time is given with a precision of 1 millisecond, even though there is nothing I do in my life that has a precision of 1 millisecond. So a major failing of the date/time libraries in Java and other programming languages is that there is good support for accuracy, but little support for precision.

The same issue occurs in the XML world too. The W3C XML Schema language forces time values to be accurate to the nearest second. If I want to represent the opening and closing times of a store or service, I have to write 9:00:00 (9am) and 17:00:00 (5pm), even though the store or service makes no promise about opening and closing so precisely. So if I write times this way, I am conveying an accurate description of the times, but I'm giving the wrong impression about the precision. Indeed, I'm probably misrepresenting the business rules, and it is always dangerous in computer systems to be misrepresenting business rules.

Try and avoid gratuitious precision whenever you can. If you get the chance, remember to lobby your favourite programming language or XML schema language to do something about it too. There is nothing to be gained from being inaccurate about precision.

Re-use and Robustness

Re-use is a mantra for a lot of software developers. The key idea is that where the same functionality is used in different places, you should centralise and share the necessary code so that it only has to be maintained in one place. This means that when a change needs to be made, that change is automatically applied in all the places that the functionality is used. This is well known stuff, I'm not telling you anything new here.

Robustness is something that nature is very good at. Animals and plants show a great adaptability to new and changing conditions. Nature makes use of re-use as a technique. Our DNA contains much in common with that of most of the animals on the planet. However, there is a big difference here from software re-use. Nature does not centralise the DNA. Nature copies-and-pastes DNA from one animal to the next, and then lets it change from there. If a species of animal suddently evolves wings, that doesn't mean that you or I will suddenly evolve wings, because we are now working from separate copies of DNA.

Am I suggesting that nature has it right and software developers have it wrong? That instead of centralised re-use, we should do copy-and-paste re-use? Well, yes and no. What I am suggesting is that both of these techniques are necessary in software development, and it is important to think about which is the better re-use technique in different circumstances.

There are various ways to implement centralised re-use of software. The traditional way is to share libraries of particular functions. With the rise of object-oriented programming languages, inheritance mechanisms are now a favoured way of sharing functionality. Other re-use mechanisms can be more subtle. For example, sometime a single XML schema is used to represent a superset of many messages that can be sent between systems. That is a kind of sharing; sharing and re-use are just two names for the same thing in this context.

So what is wrong with centralised re-use, then? Well there are a couple of things to watch out for. A centralised library of functions means that you can apply bug fixes to just one place in the code. That's good, right? It would be good except that it also allows you to introduce new bugs that can impact everyone who is sharing that library. When your library is used by mission critical systems, that can be an unacceptable risk.

Suppose you have 10 applications that share a library, but each only uses 50% of the functionality in the library. They won't all be using the same 50%, of course. There may be a bug in a function that affects only 1 of the systems. If you roll out a new version of the library, you risk introducing new bugs that could affect all 10 systems. Is it worth affecting 10 systems to fix the bug in 1 system? In some cases, it just won't be worth it. This is the kind of situation to look for, where you should follow nature's lead and copy-and-paste instead, at least for the functionality that should no longer be shared.

The rule here is that some of your current shared libraries will need to be forked in future, i.e. cut-and-pasted to produce multiple versions of some of the previously shared functionality, each version catering to a different use. Even without the risk driver for this approach, it is also well known that if you have too many separate sets of requirements for a single shared piece of code, what you end up producing is complex and hard to maintain. Your shared code may not be able to be all things to all people. A key reason for centralisation is to simplify maintenance, but you have to watch out for centralised code which has become so complex that it is harder to maintain that would a set of separate and simpler copy-and-pasted versions of the code.

For the XML world, the single monolithic schema approach to message design has the same issues. If systems have to share a single XML format for many functions, then the format has to change whenever just one of those functions change, and the change could impact every system unnecessarily. Having many small schemas instead of one large schema may sound like more work to write and maintain, but the payoff comes when you can change the schema for just one system without having to change the schemas that affect the other systems. That means you avoid having to re-test all of the other systems, and you avoid introducing any extra operational risk to those other systems. Testing is never a 100% catch-all, so if you change anything, you can't avoid the risk that you will introduce a bug that will bring down a production system, possibly with expensive consequences.

There is clearly a balance that you need to find. My personal solution is to start by sharing code, because centralisation is good wherever different systems really do want the same thing, and really do want the same bugs fixed at the same time. As soon as there is too much divergence between the requirements of the different clients of the code, that is when you need to fork the "DNA" and do some managed copying-and-pasting.

Some of these issues were touched upon in a presentation I gave on "Schema design when the goal is loose coupling" at the recent XML Summer School in Oxford. They will also be part of my talk at XML 2005 in November.

Why mention this at all? Simply because in my day-to-day consultancy and standards work, I continually come across people who insist on sharing code or using a single monolithic schema, even when the complexity of doing so is clearly hurting them. Sometimes you have to put those textbook mantras aside, and really consider all of your options.

XML 2005

The photo of me that I currently have displayed was taken by Norman Walsh at the XML 2004 conference in Washington DC.

This year's XML 2005 conference will be in Atlanta, Georgia in November. I will be speaking on Wednesday 16th November at 4:45pm on "Creating and Maintaining Large Families of Related Schemas".

I will again have my RISA Uke-Solid-Tenor (electric tenor ukulele) with me. I was inspired when I saw the "Concert for George" (Harrison). He apparently carried a ukulele with him whenever he travelled, and I also like the idea of having something with me that helps me unwind when I'm travelling. The big difference, though, is that George Harrison was a great musician, while I am just a hack who plays for his own amusement.

Unleashed

Last night, I felt in the mood for something a bit different, so I went to see the new Jet Li film "Unleashed". I wasn't expecting too much, but I was very impressed. This is very cleverly constructed piece of cinema, and it's actually a 3-way piece between Li, Morgan Freeman, and Bob Hoskins. I don't want to give any of it away, but I highly recommend it. It will surprise you.