Back To The Past

In three weeks the new Windows 9 (or whatever will be its name) will be unveiled. There are some rumors about its features but the most recurrent ones are related to the reintroduction of the Start button.

A feature introduced by Microsoft almost 20 years ago (with Windows 95) is the most awaited in 2014. Pretty curious, isn't it?

You can say that this is due to the laziness of the users and the cognitive overhead that a brand new UI implies. This is part of the truth, in my opinion. But there's also something else.

The Desktop Is The Key

When Windows 8 was released, millions of users around the world asked: "where is the desktop?" and, only after finding it, they asked "where is the Start button?" Having more than one window open and quickly switch from one to another has been one of the successful features of Windows since the release 3.0.

But at some point, Microsoft decided to switch to a more modern interface (in fact its name is Modern UI) designed mainly for tablets and smartphones. As Jakob Nielsen pointed out, it is not so bad on a small touch screen. But on a desktop wide screen it simply sucks.

So the desktop have been maintained (also because it would have been a commercial suicide to not have the support to millions of existing applications) but relegated to a small tile on the new Start screen.

The intention was clear: the future will be without application windows and with a unique interface for every device. The problem for MS is that to date Windows phones have a very small market share compared with Android and iOS so the reference market for Windows is still the PC world.

This is probably the reason that pushed Microsoft to reintroduce the Start button. For the happiness of millions of guys (like me) that don't have to explain a completely new UI every time their parents/friends/relatives buy a new PC.

Reliability First - Applications

What does reliability mean in computer science? Speaking about an application, how can we say it is reliable? I don't know if there is a shared opinion but mine has maturated after a scary situation.

Some years ago, on my previous workplace, we created a huge file with a very powerful and even more expensive third party software. But some seconds after having pressed the save button, the software crashed. Panic. We searched for the saved file and we found it. Don't panic. So we restarted the powerful-and-expensive-third-party-software to reopen the file but it failed. We tried several times even on other PCs without success. The (binary and proprietary) file seemed to be corrupted. Okay, panic!


Fortunately we also owned a licence of a similar software, much less powerful and much cheaper (about twenty times cheaper). We had nothing to lose so we tried to open the file with this cheap software and... it worked! All our job was there. So we saved the file with a different name in the cheap software and eventually we were able to open it with the expensive software.

After that incident I have a clear idea of what reliability means when speaking about applications. And you?

Image created with GIFYouTube. Scene taken from movie "Airplane II: The Sequel".

Horror Code: the Matryoshka Functions

Matryoshka Dolls
Image by Fanghong and Gnomz007
Some years ago, when I was a Windows developer, the maintenance of a big project has been assigned to me. My job was to fix a couple of minor bugs and add some new functions. The problem was that the creator (and previous maintainer) have resigned years before, leaving absolutely no documentation.

The only thing I could do was to look the code and read the few comments. At some point, I found a call to the function GetName(). Changing the name returned by that function was one of the purpose of my job, so I looked for the implementation. And this is what I have found:

CString GetName()
  {
    return GetValue("Name");
  }

Pretty useless, don't you think? OK, let's see the implementation of GetValue():

#define MAIN_APP   "Main"

CString GetValue(CString szField)
  {
    return GetField(MAIN_APP, szField);
  }

Is this a joke? Well, let's see where the story ended:

#define MAIN_INI   "main.ini"

CString GetField(CString szSection, CString szField)
  {
    char szResult[100];

    GetPrivateProfileString(
        (LPCTSTR) szSection,
        (LPCTSTR) szField,
        "App",
        szResult,
        100,
        MAIN_INI
    );

    return szResult;
  }

Surprised? Now I'm sure you are wondering why someone had done this. I'm still wondering too.

Write and Rewrite (and Make it Better)


I'm not comparing myself to Hemingway, but, when I write a new piece of software, for me it works the same. I usually write code in a quick-and-dirty way just to make things work. I have to follow my stream of consciousness and put down the basis of the algorithm.

Then, when something starts to work, I begin to make it look better. This means that I change variables like goofy, pluto, etc. with more descriptive and meaningful names. I try to see if I can move some piece of code into a function or if there is a more performing algorithm to be used. In the end, I look at errors, particular situations and memory leaks.

The final result is pretty different from the original code, but it's surely (?) better written, more readable and more performing. Maybe you can argue that I could write directly a better version and limit the modifications to small cosmetic things, so I would have saved time.

My answer is that it's not so easy. For example, managing error codes and particular cases or finding meaningful names for variables and functions is something that takes some time and, if the stream stops, it probably will take longer to accomplish the work.

What about you? Do you ever follow your stream of consciousness? Or do you prefer to immediately take care of all the details?


Image create with Pinwords - Picture of Ernest Hemingway taken from here (public domain)