Data models in DBs and GUIs differ

There can be a huge difference between the data model used in a database, and the data model that the user needs. There can also be multiple data models in the same system, based on a single database data model.

When you learn about databases, the first books about databases have a direct match between what is in the database and what is shown to the user. A typical example is a customer list, and one record in the database is one customer. You would look up one customer at a time, assign a sale to one customer etc. Everything is consistent and nice.

But once you try to support the planning and registration of human actions, things get more complicated. When did your sales activity start? At the first thinking of selling to a customer, when you made the first call, or when you started the current call? A database may register all the activities you made, but what if you planned 2 calls to a customer in week 19, but made 1, which of the 2 calls did you miss to make? Does it matter? Well, not if you ask that way. What if you ask, was the sales person lazy, ill or unorganized? The management wants to know.

The same happens in hospitals. Seen from a legal point of view, a prescription is made by 1 doctor. So, when a doctor prescribes antibiotics, it is a kind of a mini-plan. 3 times a day, the patient must receive this antibiotic drug. When does the plan end? Sometimes, the doctor does not specify that, and another doctor makes the decision to stop. Or, the other doctor changes the dose. Or changes the antibiotic drug. Maybe suspends the drug for 12 hours because of a surgery, and then makes a new prescription to start the antibiotics again. Maybe the plan continues during surgery but is just not complied to. Maybe the prescriptions are entirely stopped and restarted later. To the patient it doesn't matter what the plan is, it only matters what drugs the patient received. But to the doctors and nurses, there is a difference in overview, planning, preparations, accountability etc.

How should this be shown to the user? The doctor needs an overview, that shows all edits of a prescription as a continuation of the same prescription. Legally, it is a replacement of the old prescription with a new prescription, but for an overview, it should be considered to be one. If the drug changes, or the concentration, that does not apply, of course, the doctor then wants to see the new prescription in a separate line. So, 10 prescription records can be come 1-10 lines in the overview. For the nurse, other rules may apply. For instance, some drugs require that the drug infusion pump does not stop, so the new drug has to be started before the old is stopped. So, there is an overlap, and that has to be very clear to the nurse, but not necessarily the doctor.

For some drugs, the total amount of drug given, during the patient's stay, is important. So the totals have to be calculated across prescriptions, even if it has been suspended for days. For statisticians, they want to know the duration of the antibiotic treatment, and sometimes consider the replacement of a drug with another drug as a continuation. Additionally, prescriptions can be continuous (infusion pumps) or repeated (e.g. tablets given at specific hours). This subdivides the data models, in some cases, and not in other cases, into multiple data models.

In other words, the data model differs by the use case, even though there is only one data model for the database. This requires a conversion of data, from the database data model, and this conversion has to be applied in multiple places: Each user interface may have its own conversion, and when copying data to a data warehouse, multiple copies with different conversions may take place, in order to provide data in several ways, for easier analysis. And, once the statistician starts analyzing, more data models are needed, and data may be converted again.

Very often, in simple systems, the database data model will be close to the known use cases. However, if a new use case arrives later, this will cause problems. For instance, if the use case is to register the number of cigarette packages per week for a patient, and this becomes the database data model, you cannot easily change it to cigarettes per day later, as the package size may not be the same for all brands, and the database would lose history if the old values are simply multiplied.

In order to prepare for many use cases, the database data model must therefore sometimes deviate significantly from the user interface, sometimes generalized data structures become a very good thing, e.g. by adding records in generic tables instead of adding fields in domain-specific tables. Editing data in such a database requires a good transaction management and good maintenance of database consistency. Hospital software is full of examples of this. The art is to do this without losing performance and maintainability, and thereby functionality and usability.

TIOBE Index update - top 4 languages are going down

The TIOBE index shows:

1. Top 4 languages are going down (Java, C, C++, C#)
2. Delphi is now significantly more than 50% the size of Microsoft C#
3. JavaScript and Delphi are keeping their share
4. R is going up, fast

It seems that there is a general move away from mainstream languages, towards other languages like JavaScript, R, PHP etc. R is probably rising because of the need for more data analytics, and large organizations have a tendency not to make paid statistical software available to employees that need it - and even universities that train doctors are now switching to R instead of STATA, SAS, SPSS etc.

For JavaScript, I heard a good recently, which it keeps being so popular: It is one of the few programming languages, that you can use without installing any software on e.g. your company computer.

Will Delphi overtake C# and Microsoft .net? Maybe - Delphi works on mobile phones, but Microsoft .net doesn't.

My personal opinion is, that you should pick the development framework that suits your needs, with regard to productivity, legal issues, tool-supplier support, longevity expectations, deployment options etc.

System architecture and QA in management

As IT becomes a bigger part of everyone's business, so does system architecture and QA. Whenever we see a big IT project that fails, the cause of the failure often comes from having management that does not pay enough attention to system architecture and QA.

I think all readers of this blog have seen managers, that take decisions based on a typical project management approach, where physical meetings and physical hardware gets more attention than the architecture of the software, or the management methods required to generate good quality software. The most recent I heard, was an IT project manager who said: We just need to make it as good as we can. However, the IT system was meant to produce vital calculations for the owner, so "as good as we can" is, in my opinion, an unacceptable attitude. Either you do it right, or you report back that you cannot be sure to do it right.

The idea of project management is actually quite simple: Always make sure to tell people who does what when, and make sure it happens. That is where QA comes in. Most IT projects are too complex to make a project manager understand the details. So, in order to help the project manager, you should have a fairly detailed QA system for your software development. This QA system should cover planning of detailed design, source code maintenance, system maintenance and how to deploy it. In addition, there are many things that are hard to verify, so you should have a documented programming culture that explains how the programmers make detailed decisions, and remember to make sure, that your programmers know it, and report if they see violations.

All this must be required by the top management of modern companies. Also, there is often a lack of review of whether the architecture matches the business model, the business direction and possible future business directions. A business may want to keep its business model options open, and sometimes options are closed by system architect decisions.

Even when system architects or other design engineers come into the management, these processes are often forgotten or not executed properly.

One of the reasons why this happens, is because humans were not created for making perfect products, or following Quality Management Systems. The mathematical perfection, that is sometimes required to get everything right, collides with other skills that are also required to create great looking products, useful products etc. And system architects are often not good CEOs. So, in the end, it usually ends up being dependent on respectful, open-minded cooperation of a management team that really knows their stuff. Not all companies have that.

35 years old Arduino-like setup with Pascal

I do not care much about products or constructions from the past, that cannot be reproduced or used, but in this case, my brother's old construction from the late 1970s made me look again, because it looks so much like what people do with Arduino kits.

This is a computer programmed using Compas Pascal or Turbo Pascal:

Specs:

1. CPU: Zilog Z80, of model Z80CPU01. This is probably running 1-2MHz. The Z80 was an extended version of the 8080 CPU, on which the 8086/8088/Intel CPU line of CPUs was built.
2. One EPROM for the runtime
3. One EPROM for the actual program
4. 5x4 keyboard on the back, suitable to be used as a 4x4 hex keyboard with some more keys.
5. Some RAM chips etc.
6. I/O pins for easy access.

Unlike today, where we can program Arduino boards etc. using flash, easily, that kind of technology was unavailable or extremely expensive. Therefore, EPROMS were used, which could easily be erased using an ultraviolet lamp, and easily re-programmed using this board, which used the Centronics port for I/O to the programmer's computer, as USB was not invented back then.

 

The main computer, that was used for programming, could be a Zilog Z80 Nascom computer, a CP/M-80 computer, or any homemade computer that was using a 8080 or Z80 CPU.

Compas Pascal and Turbo Pascal were obvious choices for this, as the compiler was fast and generated great code, and therefore boosted programmer productivity a lot.

Test-driven programming guidelines

We all know about test-driven development. How many actually do this? Well, medical device software is made this way. Maybe the tests are not automated, but developers are required to establish verifiable requirements before starting to write source code. Since you only know if a requirement is verifiable, if you know the verification method, that means that you must know a verification method, i.e. test, before you can start programming.

Let's go one level up: What about programming guidelines? For instance, if your company has introduced the OOD methods mentioned on this page by Dr Bob, how do you verify that they are actually used?

Let's take one example: Derived classes must be substitutable for their base classes. How do we verify that this works? Well, first we need to find all classes that have been derived from another class, and then we need to verify that this class works in a test that works with the base class. We can usually find all class-derivations by scanning the source code, so scanning the source code would be part of the verification method. Next, we get a list of class names, and base classes, and we then must verify, that these classes are substitutable. This can be fairly easy on TStringList inheritance, but how do you verify that TXyzClass works instead of TAnotherClass? It quickly becomes a lot of work.

So, seriously, what if there is one part of the code that violates these programming guidelines, will you care? If you don't care, but you still want to verify compliance on each software release, then you need to mark this class as approved non-compliant so that you can skip it next time, and it does not show up on your error-list on the next product release.

Most people will probably end up saying: We do not verify that we are in compliance with this principle, as that would be too much work. It is only meant to be a guideline or principle... and if they are still ambitious, they might make random checks to measure compliance, and/or make senior developers review code from younger developers before the final commit. But that means that you cannot tell outsiders, whether you conform to the principles, or not. Instead, you can only be sure that you are not conform to the principles. You can only say that you try to be as much as possible.

To outsiders, this is vague information about what is going on in a software development department, which usually reduces the quality of communication to other parts of the company. So, you may want to ask yourself this question: What rules does your source code actually follow? Can you prove it?

Turning the V-model upside down: The A-model

The V-model is well known in many software development models:

However, this drawing, which is very representative for V-model drawings, has several inconsistencies. One of them is the arrow, that goes back in time. Another one is, that it puts Operation and Maintenance into the Project Test and Integration side. I have seen many V-model drawings, and I never really felt comfortable with them. The reason is simple: The V-model drawings all assume a time axis, i.e. at the end of the project, you check if the software actually works... there is no iterative development, there is no sanity check in the middle of the software development etc.

If one assumes, that acceptance criteria and test/verification criteria are made before the software is developed, as it is known from test driven development and other methodologies, the time axis should be from top to bottom, instead of from left to right. Once you do that, the next thing is: Why is the model occupying most space at the top, and most work at the bottom? Let's turn it all around, and make the A-model:

Now we have appropriate sizing of the boxes, and the confusing time axis has been removed. Just like the V-model, it is possible to have different layers in the pyramid, and use different terminologies and methods.

So, where did the time axis go? That could look something like this:

• Project is initiated, with user needs and validation criteria
• Project is planned, with design input and verification methods and acceptance criteria.
• Project is designed, which includes the creation of automated integration tests and unit tests. These may be done in parallel and iteratively, and it is possible to apply several design reviews, validations, tests etc. as part of this iterative process. The entire A-model's test-side will be applied, and the entire SPECs-side of the A-model may be changed as part of the iterative model.
• Project has it's final test, which may include formal test plans and automated tests - but in some less critical cases, in order to shorten the time-to-market, it may not include all the manual tests that were done in the design phase.
• Product is released.

Again, many different project models can be chosen, but the big work of writing the unit tests and integration tests, is done in parallel with designing and programming. Notably, integrations between software of different vendors is often integration-tested first, before details are programmed, in order to ensure that there is a connection between the two systems, early, so integration testing is started before unit testing.

I believe that this A-model represents most software development projects better than the V-model.

Process management for software development companies

Our bugtracker system has grown far beyond bugtracking, and that is the time where you need to realize, that bugtracking is not much different from managing a construction site, a catering company or many other kinds of businesses. It's all about automating the process, and this requires a generic process-automation tool, and not a bugtracker. So, why do people still get and install bugtracking software? I see several reasons:

1) The bugtracker screenshots shows data that end-users can relate to. If you see a screenshot with states, buttons and text that is similar to what you need, it feels comfortable. There are fewer things to check, than if the screenshot doesn't show anything that relates to what you want the software to do.

2) Integration with your existing tools. Things are much easier when things are integrated, right?

However, sometimes we need to make a choice, between what is right to do, and what is easy to do. If you can save 100 mandays by investing 10 mandays, it becomes a no-brainer. Well, if you can convince yourself, that the most tempting screenshot does not represent the right solution. It also requires that you know the alternatives, and most software developers never heard about process management tools like Joget or Bonita.

We have a list of possible tools to choose between, but we have not decided, yet. If you know good process management and production planning tools that make Bugzilla, Jira, Mantis, Team Foundation Server and Redmine look old, leave a comment.

Google+ is a different approach

Many try to compare Facebook with Google+, and often they conclude that Facebook har more friends, so they will not switch to Google+.

However, Google+ should not be analyzed as a Facebook killer. It isn't. Facebook has a huge head start, and even though Google+ has grown extremely fast, most current users were already gmail users. For those that do not have Google accounts, Google+ is not as obvious.

It is not a good idea to compare two systems using a one-dimensional good/bad scale, there is much more to comparisons than that. Initially, Facebook really annoyed me, because each country in Europe had it's own network, and you could only be part of one network. Then, they removed that feature, and few people really noticed. Then they added groups, then they hid them well, then they added friend lists, then they added "Top news" and so on. The core of Facebook, that has persisted all the way, is a friend list and posts, and the ability to keep the profile 100% out of search engines.

Google+ has a different approach. The core seems to be the friend list and circles, but the friend list can include people that do not acknowledge the friendship. The profile contains part that cannot be hidden from the public, such as the name and photo. So, the list of friends works differently and the circles are part of the core user experience. By doing that, Google+ will be able to do other things than what Facebook can do, and generate a different user experience. It's like comparing a bird with a human - both have skills that the others have not, but some skills overlap.

There is no doubt that Google will integrate their services further. The Google+ account is used almost everywhere, from blogs to email, and circles are now supported by Picasaweb, Google Latitude, Huddle and Hangout, but will probably also come to Google Docs, and maybe we will see Google Groups reinvented as "Shared circles". So, instead of sending emails to the scout parents, you can now post on Google+, and some will receive the messages there, some will receive it by e-mail. Those that have Google+ accounts will be able to discuss the message online, immediately, without spamming people's mail boxes. And you can keep it totally separated from your Golf club while still handling messages from both in the same place.

So, what does Google+ kill? Well, currently, not much. But it will improve sharing of information, especially among people that already have Google accounts. But because the fundamental mechanisms are more advanced than on Facebook, more can be built on it. Facebook will continue to have the advantage of size for quite some time, which should technically put it in the position of being able to compete well, but because of Facebook's reputation, many may not perceive it as a serious way to share important stuff.

Will people have time for Google+? I believe that they will, because it can be a more efficient way of spending time, than looking into e-mails and various other online forums.

Is WPF+Silverlight dead on Windows?

Does anybody still remember WinForms? If you think WinForms is old outdated technology, and WPF is the new and cozy, you might want to go on Youtube and look at the Windows 8 previews. Microsoft was dead serious when they embraced HTML5 and JavaScript last year, HTML5 and JavaScript seems to be the new toolkit for writing GUIs for Windows. In case that you wonder how JavaScript relates to other programming languages, have a quick look at StackOverflow's question on strangest language features. My personal favorite is the one about the JavaScript truth table.

A quick Google search informs, that:

* Microsoft is very quiet on WPF development. I guess they have to be, in order to support the new HTML5 strategy.

* Discussions on blogs about WPF+Silverlight contain a lot of "It will still run on Windows 8" - but not "This is how apps should be built today" or "WPF is still Microsoft's strategy for making Windows 8 apps"

I am not surprised. Microsoft keeps renewing itself, by abandoning old development tools. It has been this way ever since... well... forever. Who knows, maybe they will invent a new paradigm for NUMA cpus, that abandons compatibility with programming languages based on Garbage Collection. Or they will adopt Python and a new version of C++ as their new primary development languages. If you're in doubt whether these statements are jokes from my side or not, don't worry. I'm in doubt, too, and Microsoft does not really explain the choices this time. Explanations don't seem necessary any more, other things are more important, things move on, and "developers, developers, developers" is history.

Interestingly, Delphi 1 source code made in 1996 still compiles with Delphi XE today, with the same GUI forms, and it still outperforms .net and Java on speed, while having a similar complexity level and developer productivity. Now, this is impressive technology.

OOP Spaghetti code explained

The term "spaghetti code" is usually attributed to pre-OOP code, but there is a lot of OOP code out there that is definitely entangled and a mess. I have seen quite some of it in my carreer, and this kind of spaghetti is characterized by its dependencies.

An class is nothing else than a data structure with associated code, mainly written in a way that puts both into the same source code file. However, if a method for class A depends on a class B, it generates a dependency from class A to class B, no matter if this method is used or not. If class A is about business logic (e.g. "Customer"), and class B is an API thing (e.g. "File"), then the problem isn't that big. A smart compiler can figure out that the method is not used, that there is no active reference to "File", and then maybe not include the File object in the final app. However, if both class A and class B are of the same level in a hierarchy, for instance, if A is "Customer" and B is "Product", then it is usually the beginning of a messy friendship. It doesn't take a lot of these to create a hairball. It gets really bad, if a lower-level class depends to an upper-level class - for instance, if a MySortedListImplementation depends on AppSettings, which depends on Customer.

Why startups don't use .net

There have been several articles over the last couple of weeks about the usefulness of .net for startups. I will mention three:

* Did the Microsoft stack kill MySpace?
* Why we don't hire .net programmers
* Why Microsoft could kill your startup career

Even though our company is now several years old, our HQ is still located in an office facility that is mainly for startups. Well over the time we have had many companies, including Microsoft, Mozilla, IHTSDO and a few others, but most of the companies are startups. I recognize the same thing: I have not heard the word .net been used by any of the startups, yet. Would I hire a .net developer? I see no problem with .net, but also no significant value of having it on the resume. There are so many other parameters that are important.

I think the last article describes the problem best: Do large companies use their software engineers well enough? I think most have a problem here. A good software engineer is a serial decision maker, who writes down decisions about how things should be done in an automated way. Seen from the management POV, this is not a deterministic process, but a stochastic process, simply because the human mind is shaped by so many things, that influences the outcome. Many attempts have been made to improve the value generated by software developers, including agile software development processes, better ways to write specifications etc., but often these methods are confined within the software development department. If you want to get problems solved, for real, a larger part of the organization needs to be involved, thinking out-of-the-R&D-box must be allowed, and innovation must be rewarded.

Is there a correlation between having spent many years on .net, and not being a good choice for startup companies? It seems so. But it is not about the technology.

Apple leaves the PC era

In the recent iPad 2 announcement by Apple, Steve Jobs revealed, that Apple now earns most money on post-PC products like iPad, iPod, iPhone, Apple TV etc. This tendency does not need to continue for a long time, before the Mac computers are reduced to merely strategic products for the company.

Why Microsoft and Nokia have a chance

Many iPhone and Android fans don't believe that Nokia and Microsoft have much chance to succeed. While everybody agrees that they wouldn't have a chance without good partners, few seem to agree that they can do much together. The most frequent explanation is that their level of innovation is too low, and their R&D doesn't really work.

Most people, however, don't care about the phone producer's level of innovation. Even Apple consumers don't - they just want something that works. Nokia has been quite good at this, and I still think that S40 is a great OS for a phone if you don't want it to do much else than call someone and write an sms on a device that has a great battery life.

Nokia S60 was a usability disaster, but as long as sales were strong, Nokia believed that they were doing the right thing. Now they know that they didn't. The main problems are navigating the menus and application availability. WP7 seems to solve the primary usability problem, quickly.

So, who are Nokia's customers now and in the future? They already most of the techies to Android and iPhone, and the remaining customers often don't even know whether their phone is running S40 or S60. The OS choice doesn't matter to them. What they see others do, and want, is online address book sync, and access to the most important apps, like Facebook and Angry Birds, and maybe a calendar sync.

In USA, the biggest providers of mail and online address book services, are Hotmail and Yahoo. In many other countries, Gmail also has a small part of the market, especially amongst those that don't use Android or iPhone. The big question is, who will deliver the best contact book sync for Hotmail and Yahoo mail? Microsoft and Nokia are in a very good position for that. Facebook and Angry Birds are also available to WP7 customers.

So, if a customer uses Hotmail, and really doesn't care about weird app markets, which phone is best? An Android phone that doesn't really work well with his or her online mail and contact list, or a Nokia WP7 phone that just works?

I think there is a huge market for a Nokia 5310 like device, with the same battery characteristics and form factor, that can do facebook, has threaded SMS and sync the address book with Hotmail. WP7 doesn't need to do all the neat stuff that Android can do, in order to become popular.

Don't get me wrong, I love my Android phone. But a Hotmail phone makes much more sense than a Facebook phone.

The future of C#, the bloat explosion, and what happened instead

Looking back on this video with Anders Hejlsberg, about the future of C#, from march 2009, or this blog post about the upcoming bloat explosion, seems quite awkward with the current explosion of iOS and especially Android. There are numerous awkward parts in the video: The focus on objects, the "huge amounts" of memory and the statement that multithreading is the exception.

As readers of this blog know, Google has a famous quote in their designing for performance article about programming Java for Android: Avoid creating objects. Also, on mobile platforms, there is not plenty of memory, in the contrary, and multithreading is a vital necessity in order to achieve a reasonable responsiveness. Energy efficiency has become very important, and Apple even introduced a ban on runtimes. Also, Python and PHP is on the rise, it actually makes sense to raise venture capital for PHP-based projects these days.

It seems that Microsoft and Anders have simply planned for the wrong future - assuming that the trend would continue, and that complexity, bloat and computer sizes would continue to rise. However, the world has gone low-energy, low-complexity and small computers, instead.

I wonder how such a video would look if Anders was interviewed today.

Android sells better than Windows to consumers

If you combine a few news articles, things get interesting:

http://www.guardian.co.uk/technology/2010/nov/29/apple-ipad-cannibalising-pc-sales

"Gartner forecasts that worldwide PC shipments for 2011 will reach 409m units" = 1.1 million per day. It is fair to expect less than 40% of these sales to be for consumers. This is an 18% growth, meaning that in 2010, we can expect PC sales to reach 138 million for consumers, or 379.000 per day. Worldwide.

http://sify.com/news/google-says-300-000-android-devices-activated-daily-news-international-kmklkngheci.html

"Google says 300,000 Android devices activated daily"

My guess is, that in many countries, Android is already selling more than Windows PCs to consumers, and the number of countries where this happens, is increasing. Overall, we can expect smartphones as a category to outdo PC as an entire category, in 2011:

http://www.businessinsider.com/chart-of-the-day-smartphone-sales-to-beat-pc-sales-by-2011-2009-8

"Smartphone Sales To Beat PC Sales By 2011"

I just bought an HTC Tattoo for the sole purpose of using it as a server (small batch jobs, surveillance, remote control via SMS) in my home, and I wouldn't wonder if we would see more home servers running Android. It is very easy to set up and configure.

GTK+ app interfaces using HTML5

This impressive demo of a web application deserves more publicity. I am quite sure that this is not the last GUI toolkit that interfaces with generic web browsers.

R.I.P Microsoft Windows?

Microsoft is usually very good at presenting new products years ahead of the actual launch - but there continues to be a very remarkable absence of a single strategy for support of Windows applications or Windows as a well integrated desktop.

Android provides many improvements that Windows does not offer as part of the standard platform:

* Easy app discovery and installation (Android Market)
* Easy complete app removal
* Easy and tight Integration of phone book, GIS, messaging, online accounts etc.
* Automatic light control of the display
* Removes the need to terminate apps from the user
* Location
* Sandboxing
* Removes the need to think about file structures, which most users don't seem to grasp.
* Instant on
* OTA OS upgrades

In the future, Microsoft may provide many of these features, too, but it seems that it will take many years, because:

* Windows 8 seems to contain some technologies intended for improving on the mentioned deficiencies.
* Windows 8 is planned for 2012.
* It may take longer than that, before Windows 8 is out, based on Microsoft's historic performance.
* It often takes customers years to upgrade their Windows clients - some large organizations are still installing Windows XP. We might therefore not see a general deployment of Windows 8 before 2014 or much later.
* Microsoft does not make much PR about how to write client-side apps for Windows, how to future-proof them and certainly does not make it easy. Delphi is still king of doing that.
* Microsoft does not seem to prepare a platform for Windows apps that can be installed on Vista, Windows 7 or even Windows XP.

Don't be fooled about the press focus on touch devices; according to Paul Thurrott, Apple is still gaining market share on laptops, and Google is preparing a mouse-based OS, too (Chrome OS). Chrome OS seems to contain many of the features in the first list above, including the concept of installed apps.

Does this mean that Windows is dead? No, not in business, and not on the server. Some hardcore gamers and those that want "the same at home that they have at work" will still keep it, of course. But frankly, once Google Chrome OS is out, there isn't much advantage in buying a Windows PC, if you are an average consumer with no special preferences for specific software packages. Some may even just use a touch tablet with a keyboard.

So, how will the business desktop look like 5 years from now? My best guess is: fragmented.

TIOBE index decomposed

This post presents a different way to look at the TIOBE index. Of the top 20 languages, I exclude non-generic languages, like SQL or MATLAB. The next is to group the languages by performance characteristics:

Compiled languages that produce very fast apps:
* Ada
* C
* C++
* Delphi, Pascal
* Objective-C

Garbage-producing languages:
* C#/VB.net
* Google Go
* Java

Languages that produce slow apps:
* Javascript
* Lisp
* Perl
* PHP
* Python
* Ruby

When I look at products, which I consider successful, fast and slick, I see:
* Apple uses Objective-C
* Linux kernel and tools (incl. Android, Google servers etc.) use C/C++
* Webkit, Google Chrome use C/C++
* Microsoft uses C/C++
* Several successful vendors with great software in my industry use Delphi

I see problems with:
* Microsoft .net and Java apps tend to be bloated and slow
* Java apps on Android are not as slick as Objective-C apps on iPhone
* C#/VB.net programming requires that you are willing to bet your investment on Microsoft, who has lost major market share in many form factors
* Large apps or frameworks built on PHP or similar, simply fail to deliver

Looking into the future, where we will need one language to write one app that runs on multiple CPUs with each their own RAM, or NUMA, the compiled languages will do just fine, but the garbage languages need to be replaced with something that handles memory allocations differently.

What Nokia must do to stay relevant in mobile

Nokia is losing market share fast, which is being discussed in many places. Nokia's CEO Anssi Vanjoki also expressed his view on this topic.

The number of mistakes, that Nokia currently does, is huge, let's take a few:

* Focus on OS technology instead of customer-centric parameters. As Anssi puts it: "The current phase of MeeGo development is looking awesome."

* Believing that the window of opportunity for game-changing devices is still open. Anssi still believes that Nokia can outsmart Apple and Google, creating killer phones and market-changing mobile computers.

* Totally cutting off the pad/tablet form factor, as Anssi puts it: "the computers of the future will not be tied to a desk or even a lap – they will fit in your pocket"

* Putting the bets on multiple platforms (Symbian doesn't seem entirely dead, yet, from a product perspective)

* Demonstrating bad products. At the Open Source Days in Copenhagen, Nokia demonstrated their Maemo based phone, which enables you to have a long conversation with the Nokia representative while it is starting the maps application.

Nokia still delivers most phones, and in some countries they are absolutely huge, delivering a lot of value for a low price. However, almost all early adopters of smartphones in Europe and USA seem to have moved towards Android and iPhone, and statistics shows, that Nokia smartphone users aren't using the internet part of their smartphones nearly as much as Android and iPhone users. In other words, if the phone market would be segmented by amount of internet use, so that smartphones are the phones on which the users have heavy internet use, Nokia would be almost a non-player in the smartphone market.

However, all is not lost. Nokia can produce and deliver real smartphones to their existing and loyal customer base, and if a significant part of these switch to Nokia smartphones, Nokia's market share will jump to very high levels.

However, Nokia needs to start doing a few things right:

* Realize, that if a large organization like Nokia cannot learn quickly enough during the last 4 years, they will also be slow during the next 4 years. Nokia is big. Instead, buy other companies, and let their technology become the new big thing, instead of doing everything in-house. Normally, the largest player in a market wouldn't do this, but if they don't, they won't be the larges player in the future.

* Realize that women will want a small stylish phone and a 4-8" screen in their purse.

* Understand that the consumer doesn't care about operating systems. To the consumer, Android is not about Linux, it's about the Android Market. By promoting Maemo and Meego with an empty app store, Nokia doesn't build up momentum, it's actually destroying the value of the Maemo and Meego brands. Every time a consumer asks a friend for advice about Maemo and Meego, the answer is: "Don't touch it, that's not where the apps are". These advices are remembered for many years, and ads don't change that.

* Realize that functionality is the key to buying a phone, and that it takes years to build a good app market. A facebook app is not enough, you also need the Tour de France apps, the local bus company's app, the university campus apps etc. Developer mindshare is important, and that is probably what Nokia has been losing at the fastest pace.

* Realize, that the real innovation done by Apple, is to make the touch user interface for mobile phones. Even the original Palm Pilot had apps and a similar application chooser. This innovation has started a chain of innovations that just continues in the fiercest competitive environment that the world has seen for a long time, with whole value chains competing for innovation on all levels. Nokia has no chance to outperform this competitive environment significantly, and will have a very hard time to create a killer phone or a game-changing product, if not impossible.

* Realize, that online services are the key to apps. All mobile devices can do games, but the real value to a phone comes, when an online service is available as an app, providing device sensor integration, a good touch UI, offline / bad network capabilities, app/share integration etc. Nokia tries to deliver their own maps product, their own e-mail system etc., but in order to become the biggest map provider, they also need to compete on the computer desktop for the user's attention - being only a map provider on the phone is a losing strategy. But Google is a very large enemy here.

* Realize, that it makes sense to be a huge company that does everything from producing hardware to software, in the mobile industry of the 1990s. But in the 2010s, the business model doesn't favor that. It is similar to the steel industry - they needed to be huge once, when capital costs were huge, but when the cost structure changed towards variable costs, the biggest steel industries got serious competition from very small players that they could not compete against. Nokia should look into the steel industry and learn from that. Quickly.

Apple iPhone 4 signal strength indicator highlights a common problem

It is old knowledge that if progress bars go faster at the end, the user is happy. In other words, if the progress bar is modified so that it doesn't show the perfect progress percentage, you get a better customer satisfaction.

The same principle applies to other indicators, like battery indicators and mobile phone signal strength. Many phones don't seem to lose battery energy until the very last moment, where it drops fast. Apple has now communicated, that their antenna problem actually isn't that bad, but their signal strength indicator is very sensitive at the coverage levels where this problem was demonstrated. Apple will now "adopt AT&T’s recently recommended formula", which should improve on the problem. That doesn't change the fact, that a piece of rubber can improve the iPhone 4 significantly, of course.

The Google Nexus One has a different approach on battery indicator than most: It starts to drop pretty fast after charging to full level, but when the battery indicator is low and red, you actually still have a lot of energy left - 20% in the indicator means about 20% to go.

What is the best solution? There is a commercial side and a usability side of the problem. The commercial side depends on your business model, and I won't get into that here, but the usability side actually doesn't give a clear answer, either. We have several processes that we want to support:

* If the user needs to plan usage of a limited resource for a specific amount of time (e.g. battery energy for one day), the indicator needs to progress during the entire time span.

* If the user normally doesn't care about usage of a limited resource (battery energy), but may end in a situation where the limited resource is sparse (battery almost empty) and then starts to care about it, the progress indicator should progress little during normal use and most when resources run out.

* If the indicator is used to indicate chances for downtime (e.g. signal strength), it should be most sensitive for high downtime probabilities.

* If the indicator is used to indicate rate of energy usage (e.g. signal strength), it should be most sensitive at the rate that is used most frequently. This may be in the upper or lower end, or in the middle.

* If the indicator is used as a provider of a value, on which the user wants to do calculations, the indicator must reflect reality in a way that is easy to interpret. For instance, if you have 5 bars for battery, each could represent 20%. Or if you have 5 bars for signal strength, each could represent a factor (constant amount of dB).

In other words, there is no perfect solution, it will always be a compromise.