Derivatives in IT: SaaS

One of the major causes of the financial bubbles is derivatives. In theory, they're a good thing, but even though they seem very easy to understand, they're sometimes too complicated when things go wrong, and they can bring down entire companies.

We have something similar in IT: Software as a Service. In theory, it's a good thing. You can build entire companies on top of it, but even though it seems very easy to understand, it's sometimes too complicated when things go wrong, and it can bring down entire companies.

Many things can go wrong:

* Your provider may go bust. Needhost.dk just went bankrupt, and customers have no access to their data any more. There was no warning.

* Network connections deteriorate to a level where the software does not respond well enough to be usable. Almost no company provide enough metrics to be able to specify a minimum service level that solves all thinkable problems.

* Network connection bandwidth may deteriorate to a level where your data can no longer be transferred quickly enough to make backups or to move to another provider. And who knows, maybe your data is physically stored in Siberia?

* Power outage may hit one of the many connection points between server and client.

* The provider may not be able to allocate enough employees to help you out, especially if a problem hits all the provider's customers.

Usually, SaaS contracts are based on historical performance, like "our network has 99.9% uptime". They should write "had", because if uptime drops, the customer has a problem, no matter what the contract says.

Businesses usually rely on the fact, that if something goes wrong, there is usually a workaround. However, broken cables in the Mediterranean sea, or censorship can block entire ranges of IP addresses. Court decisions may block DNS names. If your country loses the connection to your SaaS provider, can your company continue without?

The solution to all this is easy: Make sure that your company can continue, if your SaaS provider stops its operations with no warning.

Top down programming using refinements

In 1984, I enjoyed learning the Elan programming language. It had a nice syntactic element: Refinements. These are used for top-down programming, which means that you decide what your function should do, first, and then write the code, later.

Refinements couldn't do anything that procedures and functions cannot do - but it was a nice element of the language, that its syntax actually focused on the principle of top-down programming.

It works like this in Delphi: Let's write a procedure that sorts a file, line by line. Here is our first code:

procedure SortFile (filename:string);
begin
  // Read file into memory
  // Sort the lines
  // Write file out of memory
end;

In Elan, the comments would be refinements, and you would write the actual implementation elsewhere. Delphi doesn't have refinements, but you could write procedure calls instead.

Another method is to implement each of these comments by actually writing the code, letting the comments group the lines:

procedure SortFile (filename:string);
var
  sl:TStringList;
begin
  sl:=TStringList.Create;
  try
    // Read file into memory
    sl.LoadFromFile (filename);

    // Sort the lines
    sl.CaseSensitive:=False;
    sl.Sort;

    // Write file out of memory
    sl.SaveToFile (filename);
  finally
    FreeAndNil (sl);
  end;
end;

This approach usually leads to very readable procedures. Usually, it also means that complex algorithms are written using several small and simpler algorithms.

Touch typing leads to a different choice of tools

It is a disgrace, that the amount of people that are able to touch type, is not increasing. Many user interfaces today optimize the input of data by providing a context-based list of choices, so that the user can easily pick what is needed. Mobile phones excel at this, but if you want to be really efficient with a computer, you need a higher bandwidth between you and the computer.

Without touch typing, a programmer often does about 20 words per minute. A touch typing programmer easily approaches 80 words per minute or more. However, the really big difference, is that the touch typer focuses on the task, and not on the keyboard. Touch typers are usually able to involve themselves in a discussion about something else, while touch typing.

Touch typing also decides the choice of tools. A good example is computer games. Everybody can sit down with a playstation and play some games. it takes much more to learn 25 different keys in a complicated PC game, but those people that like PC games, often dislike console games, because of the lack of bandwidth between the user and the PC.

However, touch typers also program differently and use applications differently. It's not just about speed, but also about how problems are solved. As you can see in the video, it takes less than 3 minutes to type this blog entry.

Delphi in the Cloud, Virtualization and other new inventions

Buzzwords change all the time, and the newest is the Cloud. The cloud provides several benefits: deployment, load balancing and costs improve a lot. Where does this put Delphi?

What we see now is the first generation of cloud systems. Some clouds have specific programming languages, very specific APIs and even specific databases which are rather primitive. As a former technical responsible for a webhotel, I can certainly understand why they don't introduce full SQL support from the start. However, as time goes, things becomes more feature-rich. We will see more support for SQL, more support for various programming languages, and maybe even support for virtual machines in clouds. It will be possible to create a virtual machine and put it into the cloud, replicated as many times as necessary.

Delphi/Win32 is very much about GUI client creation. It does not need a cloud, but it connects easily to a cloud. Even the Windows Azure client technologies are directly available in Win32.

Delphi Prism works with Microsoft Cloud technologies, but basically works with any mono-compatible cloud technology.

The only thing that is missing in this piece, is a good super-scalable cloud database that treats transactions just like Firebird does. Delphi has a good history of being able to handle many kinds of database semantics, and therefore works very well with almost any type of database in the cloud. However, the age-old problem of distributed transactions has not been solved with the cloud, and therefore we will still see many apps with centralized databases.

The current state in many organizations is, that they're trying to consolidate and virtualize. The cloud is nowhere near reality in most organizations yet, and we will see a lot of improvement in Cloud technology before it becomes mainstream in business.