firefox 2 beta 2

I got nothing to do today, and there is a long weekend ahead. I had thinking of trying Firefox 2.0 beta 2 since it was released Thursday. (Also, I wanted to write a blog with lot of colorful pictures for a long time ). Well, at first I accidentally download the German version (I followed the link from a blog. Even though the blog was written in English, it lead me to the German version.). Even though the installer spoke German, I went ahead and installed assuming that the problem might a locale setting or something. Then, I figured out that there are separate versions for each language.(Why ? ) Anyways, I then downloaded the English version and fired up the installer. The installation went well and, when it tried to import the extensions from the existing installation of version 1.5, most of the extensions were not compatible.

Yes, I was warned about incompatibility, while I downloading. So, no complaints here. But there is a really nice option for the rest of the working extensions (now called Add-ons). Add-ons, now, can be disabled with a click. Hooray!! Long live the add-on Gods!!!

The basic UI looks the same. Some cool tab features have been added directly into the browser. A new option for tab has been introduced, which has basic feature of any tab++ extensions out there.

An easier way to get to the list of all tabs is something, I have always wanted with in a browser.(I mean, a browser with tabs function)

 

And the one that impressed me most is the feeds options. Now you can redirect any RSS/RDF/Atom links to your favorite feed reader directly from the browser. You just have to do this…

A special mention – Built in “Restore Session after Crash”.

But I don’t know why the QuickTime plug-in still crashes on me. I am still not able to see the new apple ads.(It does to me even in Firefox 1.5, and IE 6.0. Bad Computer! ) Also, the bookmark explorer crashes, when I try to change the properties.

On the whole, Firefox 2.0 looks good with lots of nifty features. But I see that the features of popular extensions are slowly creeping inside the browser. I hope, it doesn’t bloat Firefox.

why can’t software be like an aircraft engine ?

When dealing with software professionals, the users tend to asks questions like why the making of software doesn’t work, exactly like their actual job. And when you make a software for the engineers who design, develop and test Aircraft engines, they seriously ask questions like why this software can’t be like an aircraft engine.

I get really excited about such comparisons. When it comes to software, I always hold the opinion that there is no comparison that fits. I wish the poet Pablo Neruda had written some poems about making software. Then, at least, we would not have this shortage of good metaphors.

I wrote a blog entry sometime ago about what I do for a living. I can say it again – RSA wouldn’t mind it actually – I work on a team of customizing an Engineering software for an Aircraft Engine manufacturer. We work on a monthly build cycle, that works fairly successful in fixing bugs and introducing a new feature every month. In plain words, we put in a new version of the software every month for our users – with a new major functionality and a few bug fixes.

There are no dedicated testers here. (Yeah, I know. Just give it a break. It’s just a customization project). Its the actual users who test it in a simulated test environment, before we push the software to the real time, live wire production environment(Again, with the shortage of metaphors in Software Engineering, we use buzzwords!!!) . In the previous build, it happened that the testing for the major functionality was complete, but the bug fixes – We couldn’t get enough users to test them!!! Obviously, we can’t push the software to Production, until we are sure we aren’t breaking anything with our “fixes”. So we had to delay the build a week. When we told that to our clients, one of them had this to say….

You are saying that you can’t push the software to prod until the bug fixes are tested ? Its like saying – Even though the nozzle assembly of the engine has been tested for every other performance metric, and just because a small component such as a bracket is not available, I can’t ship the engine. Can’t you just pull out the bracket ?

When all of our customization is built and bundled into a single shared library (All of them are in a single binary file), it is impossible to pull the fixes from the dll file. Sometimes, I do wish I have some supernatural power by which I can rip apart the bytes of that binary file, and pull out the ugly “brackets”, I wish I had not made. (The main reason would be – save some embarrassment.)

Unfortunately in Software Engineering, we are still trying to figure out how to do things better. And all I can say is that making parts of working software into components hasn’t reached the level of granularity of building an engine – to its bolts and nuts.

It is not impossible. (Pardon the double negatives. I need to be explicitly equivocal here.) You just need a highly flexible version control system, probably use a scripting language instead of a compiled language (a framework like Ruby on Rails ???), then a perfect system of tagging, naming, arranging builds, then of course, a reliable system of automated testing, and then finally a highly granular configuration system – seamlessly integrated with the rest of them.

If we can have all that systems, then probably we can “pull out” stuff that is not required. In short, it is just not like pulling nuts and bolts or even a bracket out of an aircraft engine assembly. (Or it could very well be just that the comparison of bug fixes in a software to a bracket in a engine could be wrong. I told you – We badly need Neruda)

software requirements

Ken is one of the guys, who explains to me, the standard procedures defined for Engineering Changes for his company. The responsibility of me and my consulting team is to customize and to maintain a commercial software product, to suit his company’s process needs.

Let me try to explain of what is that I actually do for a living. Here is a company that builds aircraft engines, which, not surprisingly, is made up of thousands of components. To design, to develop, to repair, and to service these components that make aircraft engines, not so surprisingly, this company gotta have hundreds of Engineers working on these components – simultaneously.

And those Engineers work hard. Engines are made, and sold. They are installed into nice, big airplanes. People fly on those airplanes all over the world… yada, yada, yada, and the whole world is a happy place.

Now lets say, a component, that goes into such an aircraft engine, requires a modification for engineering reasons, such as, a re-design to handle more pressure. Or Probably, it has to be modified for quality requirements, such as, a change in the inspection method. Well, if we have to change it, Why don’t we just do it ? Not so fast, Young man!!!

When hundreds of engineers working on thousand different components, obviously, we need a standard process of doing it. Also, we need a pre-defined way of documenting those changes, so that we can go back or reverse the change, if needed. Now, go back to first paragraph… Just read the first paragraph, and come back here.

So, now you know what I do, right ? Yes, that’s what I do. If you didn’t get it, I can say all that in a line – I make a living by trying to make a commercial software work for a business.

So, Where were we ? We were talking about Ken. Ken and I were talking about how to keep track of a component, that is just lying there, and is never used in any engine – Of course, using the software. Well, the process and the software is already there, and Ken just wants to know how it works.

When we were talking about another related functionality, I said that it is already there, and showed the paragraph in the documentation explaining it. He said,

I know this requirement. But we forgot what we meant, when we asked you to do it. If you could say me, how you made your program to do this, then, we could know what we meant, when we asked for that.

And he laughed. Then, I laughed.

I was reminded of this Dilbert Cartoon, when the analyst asks the user for his software requirements. The user asks the analyst to make a software that would tell the requirements. In Software, it is always like that.

When you buy a car, you exactly know what you are buying. When you buy a software, you really don’t know what you are buying. When you put your hands on it and start using it, you wonder “Did I really pay for this ? Why did I ask for this ?”. That’s why it is so difficult to define a software requirement, especially, when it is customized for a business.