Is software engineering really an engineering?

Well, according to all the things I have heard on different lectures and read in various computer magazines, software engineering is not an engineering.

First, programming (and building a programming product in general) is offer compared to building a bridge. This metaphor is correct in some aspects. You have small pieces (functions, objects) which you combine and put together to construct a bigger and more complex system - a bridge (programming product).

But in other ways the bridge metaphor is totally incorrect. There are multiple ways how to argument this. Constructing a bridge is very well studied discipline. All the forces that have to be taken into consideration during designing a bridge are well defined. There are exact mathematical formulas that define these forces. When an engineer knows how those forces work he can design the fully functional bridge and pass his plans to builders who build the bridge exactly as it was designed.

Of course we are just humans and we make mistakes so even building a real bridge does not have to end well

On the other hand software development is not well studied at all. There is some knowledge about factors that influence the development process but this is more or less just an outline what really goes on. Some estimate that the percentage of software projects that exceeded their budgets is higher than 60%. According to May(1998) the average software development project is 187% over budget and 222% behind schedule and implements only 61% of the specified features. The average success rate of the software project is somewhere around 30% [1] - it means 25% of software development efforts failed outright; another 45% produce a sub-standard product. In what other industry would we tolerate such inefficiency. Could you imagine that just 25% of the bridges fell down or 25% of airplanes crashed?

Next thing is that software development is defined as incremental and iterative process. This is also not true in bridge building parallel. The designer of the bridge sits down, design the bridge and that`s it (well, this is a little bit exaggerating). But in case of software development there is not such thing. During  the life cycle there is a lot of prototypes and modifications of the initial plan.

There is also conflict in bridge builder vs. programmer parallel. Bridge builders are like trained monkeys. They just do what is written in desing plans of the bridge, nothing less nothing more. And the character of their work is highly repetitive. But the programmer recieves very abstract definition of his work and to get it done programmer needs a creativity. Programmers sometimes have so much of creativity that they want to improve the initial program design and it usually does have very bad consequences.

The following video lecture deals with reasons of such low successfull rate of software projects in more detail. I really encourage you to watch it. Glen Vanderburg puts it in really interesting way.

There is also an opinion that computer science is not a science. More on this topic can be found in Communications of ACM`s article [2].

[1] Watts S. Humphrey: Why Big Software Projects Fail.
[2] Communications of the ACM, Vol. 56 No. 1, Pages 8-9: Computer Science Is Not a Science

Bug fixed!

For the last two day I spent a lot of time trying to understand what does the source code of specified files and trying to figure out how to fix the auto-parenting problem. However, I am not able to prove my theory that the "Enter a conferece server" dialog is beiing auto-parented by the wrong window. I have tracked the problem to the very low level, to the implementation of the jabber protocol, from which the problematic dialog is being rised. But now there are so many function calls and so many branches that I got a little confused.

"If we knew what it was we were doing, it would not
 be called research, would it?"
    -- Albert Einstein -- 

I tried some coding without complete understanding of the hiererchy of the windows. And I succed. Albert Einstein was a wise man. I have modified the code so that I got the desired behaviour of the dialog windows. All the problems were solved by two additional lines of code and encapsulate call of one function so I could pass the parent window as a parameter (the first function is the original one; the second is my modification, which are in bold and underlined):

void pidgin_roomlist_dialog_show_with_account(PurpleAccount *account)
{
    PidginRoomlistDialog *dialog = pidgin_roomlist_dialog_new_with_account(account);

    if (!dialog)
        return;

    list_button_cb(GTK_BUTTON(dialog->list_button), dialog);
}


void
pidgin_roomlist_dialog_show_with_account_dialog(GtkWidget*parent_dialog,PurpleAccount *account)
{
    PidginRoomlistDialog *dialog = pidgin_roomlist_dialog_new_with_account(account);

    if (!dialog)
        return;

    gtk_window_set_transient_for(GTK_WINDOW(dialog->window),GTK_WINDOW(parent_dialog)); 
    gtk_window_set_destroy_with_parent(GTK_WINDOW(dialog->window), TRUE);

    list_button_cb(GTK_BUTTON(dialog->list_button), dialog);
}

Actually, for the fix of the orriginal problem only the gtk_window_set_transient_for() is required. The function gtk_window_set_destroy_with_parent fixes the problem, that when the parent window is closed("Join a chat") the window "Roomlist" stays visible and when the join a chat procedure is repeated multiple times, mulitple windows "Roomlist" stay open. The function destroyes the "Roomlist" window when the parent window "Join a chat" is destroyed.

Here I come, #10863!

So after I found out that bug #15242 is not actually a Pidgin bug but external problem of MSN protocol, I continue with my so far not very successful hunt for bugs. After reviewing some other bugs I came across one potentially interesting bug which I was able to reproduce. It is bug #10863 and here is the problem:

When you go to "Join a chat...", choose your XMPP account and pop up the "Join a chat" dialog and then click the "Room List" button, the "room list" dialog opens with a dialog window asking you to enter a conference server.

"Join a chat" dialog

"Room list" with "Enter a conference server" dialog

 When clicked on "Find Rooms" this just brings the focus back to the original "Join a chat" dialog The "Room List" window, with the actual room list (which is now unpopulated because I did not enter any valid server) still unfocused behind the "Join a Chat" dialog. So that basically every time I have to manually switch focus to the room list to get where I obviously wanted to be.

"Room list" hidden behing the "Join a chat window" but should be focused and on the top of window hierarchy.

How should it behave correctly:

When clicked on Find Rooms in "Enter a conference server" dialog the "Room list" window should be displayed over the "Join a Chat", not behind it as it is now.

I figured out what might be the problem. When the dialog window pops up asking a user to enter the conference server this dialog is being auto-parented by the "Join a Chat" dialog, not the "Room List" as it should be. After destroing the pop up window, focus is transferred to its parent window "Join a Chat" not the "Room list".

I tried to verify that this theroy is correct, however I was not able to do it. The chain of calling functions is too long and with lot of branches. I need to do more investigation. To improve the readibility of the code I renamed some functions, as their names were too abstract. 

So for now I have identified the exact place of the each window creation in the code but I don`t get the hierarchy of these windows (which windows are whose parents).

Bug #15242 seems interesting

I have finally found bug that is in every possible aspect appropriate for the bug hunting. It is bug #15242.

Describtion of a problem:
Connected using MSN, had a website opened in Firefox ( ​http://www.goodnet.org/articles/337) and tried to copy-paste the URL into the conversation - right after pressing <ENTER> got following error message:
Message may have not been sent because an unknown error occurred:
​http://www.goodnet.org/articles/337

EDIT: This morning I was trying to do some deeper investigation about the bug #15242. However, I found out that the bug has been meanwhile closed and set these properties:

• Resolution: set to cantfix
• Status: changed from new to closed

"The MSN service is filtering your messages; if you search online for information related to this, you'll find a fair amount." I found out that the solution to this problem ist just the usage of an URL shortener.

So that`s it. Problem solved.

Read all the source code in one hour - that`s a challenge

My observation from reading the code is that naming of data structures and functions are in general quite accurate and make it clean what it represents, modularization has also quite solid logical basis. However, some source code files are too huge. I think it would be good idea to split them in multiple files.

gtkmain.c - signal handlers, command line options processing, debug prints and loading the buddy window and login to accounts. And also some other interesting stuff:

• /** ... So instead we'll do an ugly hack where we write the signal number to one end of a socket pair ... */     

•  segfault_message = g_strdup(

            "Hi, user.  We need to talk.\n"
            "I think something's gone wrong here.  It's probably my fault.\n"
            "No, really, it's not you... it's me... no no no, I think we get along well\n"
            "it's just that.... well, I want to see other people.  I... what?!?  NO!  I \n"
            "haven't been cheating on you!!  How many times do you want me to tell you?!  And\n"
            "for the last time, it's just a rash!\n"
        );

• /* FUCKING GET ME A TOWEL! */
  #ifdef _WIN32
  ...

gtkblist.c - creating the main window and ist menu - list of buddies, chat groups, contacts managment

gtkconv.c - conversation stuff, open/close conversation, sending messages/files/pounces

notify.c - notifications from libpurple core to pidgin UI - buddy status change, visibility, new msg/email

Applying reverse engineering

Today we had lecture about the Reverse engineering. It is the completely reversed development process. We start with the source code of an existing system and we try to figure out the design issues and the abstractions of the given system. That is basically what we need to know for the Bug Hunting Competition.

So how to start? For our purposes we should do these:

• Do a mock installation - that is one of the first things I did, I got the latest version of the source code, built it and run it.
• Skim the documentation - I can also check this point, because I have done this also in the very begginigs
• Read all the source code in an hour - I have to pay some attention to this point, what I did so far was that I just read the source code of the second biggest source file and the file containing the entry poit of the application. Just for an info, the line count of some interesting files(these are just Pidgin files which deals with GTK+ UI):
• 10291 gtkconv.c
• 8250 gtkblist.c
• 5893 gtkimhtml.c
• 3710 gtkutils.c
• 2990 gtkprefs.c
• ...
• 948 gtkmain.c (int main(argc, argv))
• 67374 total (total 51 C source files)

What is so interesting about that? Just the fact that these 5 files (of all 51) contains 46% of the  source code. These source files must be pretty important, right?
Together with libpurple(library used for developing IM programs) and finch(console-based IM program that lets you sign on to IM networks) it is 160 500 lines of code and 138 C source files.

Contact with Pidgin community

I decided to get in touch with developers of Pidgin. I registered to mailing list on the very first day I decited to go with Pidgin to the Bug Hunting Competition. But the mail list is not very useful for me. I have recieved around 5 email, but I have no idea what are they about.

So I registered to pidgin IRC channel and wrote a message to everyone, saying that I do have problem with reproducing bugs reported to the latest release version. There was 141 people in the #pidgin room. Just someone with nick datallah had responded.

We had some discussion about the quality of the bug reports, here are his exact words when I described him my problems with finding some good bug report: "it gives you some perspective to what dealing with these reports is like :)"

Are those really bugs?

I decided to go for fixing the bug #1577 (Sort groups alphabetically). To make this feature accessible to the user there has to be additional menu item. I tracked down to the creation point of menu bar. It is used a function from Gtk API to create the menu bar. This function parses a string containing UI definition. I tried to add the definition of new menu item for sorting the "buddy groups" but it does not appear in the menu. To be sure that I am modifying the code on appropriate place I added to menu definition just a simple separator - it worked and it was displayed in the new modified menu. So I must be doing something wrong with the definition of menu item for sorting groups. I think that the problem is caused by the way I define the action handler for this new menu item.

EDIT: I could not go sleep knowing that I have not succeded with menu item creation. I searched the source code a little bit deeper and I found the cause of the problem. The new menu item was not shown, because it did not contain any submenu items. Menu structure now looks like this:

Buddies
|_ ...
  _ Show
     |_Offline Buddies
       _Empty Groups
       _ ...

  _ Sort Buddies
     |_Alphabetically
       _Manually
       _ ...

  _ Sort Groups (new menu item)
     |_Alphabetically

But wait a minute! Is #1577 (Sort groups alphabetically) really a bug? Well it was it bug trackind database but it is more a new feature request that a bug. So let`s choose something else...

Now, I am going after third bug report, it is bug #13501.

First, I have to download source of the version in which the bug was reported. The version in repository is 3.0.0dev, which is not in release state. I will try to build the latest release - 2.10.6 version and reproduce the bug.

Bug #13501 is already fixed in the latest release version, or at least I cannot reproduce it(it was reported in 2.7.11 which was released on 2011-03-11).

I have investigated a bunch of reported bugs from latest version 2.10.6, but i was not able to reproduce any of them. I asked a reporter of bug #15263 to provide more details about how to reproduce the bug.

Playing around with Pidgin

The best way how to strart is to downlad the source code, build it, look around for some documentation (I hope there will be some) and play with the code. These are my first steps:

Geting the source code:
All Pidgin Mercurial repositories are available via HTTP from ​http://hg.pidgin.im.
hg clone http://hg.pidgin.im/pidgin/main pidgin-main 

Adding the PPA to Software sources (under Ubuntu OS):
You can update your system with unsupported packages from this untrusted PPA by adding ppa:pidgin-developers/ppa to your system's Software Sources.

Installing dependencies:
apt-get build-dep pidgin

Generating make file (This short  command has actually taken me most of time. Lot of dependency files were missing so I had to manually install and configure them.):
./autogen.sh

make & make install

run ldconfig

And finally try to launch pidgin!!! Nice, it works. So the whole Sunday afternoon was not wasted for nothing.

The Code:

The source code file structure is pretty simple and intuitive, there is a subfolder in the file i have downloaded from SourceForge which contains all relevant code. This folder is also organized by very intuitive way (the source code files are nested right in this folder, while there are also subfolders for plugins, pixmaps,  themes, etc.). If i compare this structure to the one I have seen in JEdit project it is a way better.

When I browsed through the source code files, I have discovered that there is a lot of GTK stuff and a lot of signals and signals handlers. When I lunched pidgin in a debug mode, it had created four threads even before it got the point where the main window is created and displayed. For now, the structure of the program is a nothing but the dark place for me. But for the start, I can see a basic gtk program structure.

Documentation? What is that? Well, it is not so bad. Obviously, Pidgin developers know this word, however it is very brief. In most cases it consists of one short sentence for each function and 2-3 words to each function parameter. The docs is generated by doxygen, and the command to do this is included in Makefile (make docs).

I have also looked to bug tracker list. For the start I think it should not be complicated to fix bug #6825 (https://developer.pidgin.im/ticket/6825). It is just about that the text field has not the focus by default.

EDIT: After reading the discussion about the bug #6825 I found out that this is not really a bug. The reporter of this bug just request for another default behaviour which developers does not cosider correct. So I leave this bug and I try to provide patch to https://developer.pidgin.im/ticket/1577.

"Bug Hunter" Kickoff

This is the first article in the "Bug Hunter" competition series. The main idea of the competition is to choose some opensource project, get the bug list and try to fix as many bugs as possible. However, I have never done something similar nor I have worked in a project with more than 5 developers so this is a real chalennge for me. If everything goes well I hope to fix at least a single bug and post a patch to developers comunity.

For now, I am just looking around the OS field and I am trying to choose some appropriate project. I have made these criteria for selecting the project (listed by decreasing priority):

1. It should be written in a language that I am familiar with
2. The web pages of project are well arranged and has a lot of useful info for noobs
3. I should have some user experience with project


Pidgin project came out as a winner. It is written in a C, webpages are really easy to use and I have also used this program for some time.

Pidgin is a graphical IM program that lets you sign on to AIM, Jabber, MSN, Yahoo!, and other IM networks. It runs on Microsoft Windows and Unixes. It is written in C and uses GLib and GTK+.