In a programmer’s mind

Not everyone likes what IBM is doing by Looking Glass

I have started using Rational Team Concert (RTC), version 1 and 2, at work for my latest project. RTC is an IBM product based on the Jazz Foundation platform which integrates work item tracking, builds, source control, and agile planning. It tries to manage most of what a software development team will need to do with the same tool.

In that sense, it is similar to Team Server Foundation by Microsoft. You might remember my rant about it.

RTC is geared towards big enterprises. The initial cost for the standard edition is probably enough to justify not to use it for most small and medium teams or companies.

Like many IBM products, RTC tries to do everything from defect management, automated builds, planning to source code management. I must admit that overall, it does manage this feat to a good level.

Without any other delays, here is what I dislike about RTC.

It sends whole files on the wire instead of deltas

Imagine you have a 100 Megs file that needs to be modified and sent back in your central repository multiple times in a day. Let’s also pretend that you are simply changing 10 characters in that file each time. With RTC, whenever you send those changes are sent back in your central repository, the whole file will need to be transmitted on the network instead of the 10 characters.

This is simply unacceptable. It is a waste of network resources and a waste of my time because I need to wait for this transfer to complete. It seems like some operation depends on other ones and you cannot perform them in parallel. Whenever I tried to do too many long operations at the same time with RTC, it shows a model progress windows that completely disabled my ability to use my IDE.

A simple diff algorithm on the client side or on both side would use a few of my heavily underused CPU cycles and it would be way more efficient. This is one of the base concept of most version control system out there. Subversion has been doing this for years now.

It is centrally based

It seems like most people have not discovered the joys of distributed version control yet. During the course of my normal usage of RTC, I have had network failures and disconnects with the RTC server. As soon as I was disconnected, I was left in the cold dark state of anger because I could not do much about managing my source code. For that reason alone, it should be distributed.

It is treating me as an idiot who do not know what he is doing

Whenever I try to do something that might have some repercussions, it shows me a popup asking me if I am sure I want to do that. Here is a typical scenario:

1. I check-in some files while keeping some files unresolved (not checked in).
2. I associate a work item with the new changeset because it is a precondition to delivering a changeset on the project.
3. I try to deliver the changeset.
4. I get a popup asking me if I am sure I want to deliver those files without including the other files that are unresolved.
5. I confirm this action by clicking on yes.
6. There are errors in my project that triggers a precondition failure that makes me unable to complete the delivery.
7. I override that precondition so I can complete my delivery.
8. I click on the “Retry” button so my delivery can be retried with the precondition overridden.
9. I get another popup asking me if I am sure I want to deliver those files without including the other files that are unresolved.
10. I confirm this action by clicking on yes.

Those popups are everywhere within RTC. Many of them are modal ones too. I am not an idiot. I know what I am doing. Stop bugging me and provide facilities to revert my mistakes.

You cannot easily name a revision in the past

There are two named revision concepts in RTC: snapshot and baseline. In short, a baseline is for a component (a kind of project division) and a snapshot is a group of baselines. The problem is that you cannot create them for revision in the past. You can only create them for your current workspace. If you forgot to create a snapshot for your latest deployment, it is just too bad for you. If you really want to create it, you will need to update each file to the state where it was when you did your deployment and create a snapshot with the files in your current workspace. The ugly side of this is that you cannot update your workspace to look like a revision in the past easily either.

Read-only file updates make your project out of sync

For our project, we had some files that were read-only but needed to be updated once in a while. Every time we had to update those files and they were accepted on the developer’s PC, it would put the projects in the related baseline out of sync. It is a state where you cannot do any operations with RTC without having multiple popups telling you that you need to resync your projects. The read-only file updates is only one way to get your projects out of sync. We manage to reach that state in different scenarios.

In other to correct that problem, we had make the files writable and perform the resync operation. This was a real pain.

Considering the whole thing, RTC is not such a bad product. It just has many quicks that are unpleasant and difficult to bear with. If you have the money and want an enterprise product, go for it. If you do not, there are multiple free solutions out there that can do most of what RTC is doing and that can do it better.

No matter where it is going, it has to run fast by Hamed Saber

Most developers I know are worried about their software performance. They are worried to the point of nonsense. With every decision they will think about, they will immediately balance out the arguments regarding performance whether it is an architecture decision, a technological choice or a nested loop.

This does not make sense on many levels. First of all, performance is more often overrated. A fully functional and correct slow software is always better than a fast buggy or incomplete software. Clients are often asking for highly performing software but in most cases, they are satisfied with a fully working version even if it does not run as fast as they first though.

Developing with a performance mindset often create solutions which contains more bugs, are harder to maintain and are harder to understand and read. Here is a example of this. Compare these two C code snippets:

int i, sum = 0;
for (i = 1; i <= N; i++)
    sum += i;
printf ("sum: %d\n", sum);

int sum = (N * (N+1)) >> 1;
printf ("sum: %d\n", sum);

They both execute the same task. The second one is optimized for performance. Which one would you prefer for ease of maintenance, ease of understandability and ease of reading ? The first one of course.

Another reason why you should not think about optimization too much is because you cannot know which part of your application is or will be the performance bottleneck. You might put a lot of efforts with a specific section of code that is only called once in a while and fast enough.

I am not saying you should not do performance optimization, but that should be the last thing you should thing of. In my mind, I only see two reasons for doing it:

1. Customers are complaining about speed
2. You want to gain a competitive advantage (just like the current crop of upcoming browsers)

If you know any other good reason for doing it, let me know.

When you have to optimize your code, the first thing you have to do is use a code profiler to find where is the problem. There are many tools available for this and I am pretty sure there is one for your language. Here is a simple profile output I ran a few days ago for Mercurial.

         1239498 function calls (1237075 primitive calls) in 18.604 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000   18.604   18.604 :1()
        1    0.000    0.000    0.000    0.000 ConfigParser.py:106(Error)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:118(NoSectionError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:125(DuplicateSectionError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:132(NoOptionError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:141(InterpolationError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:149(InterpolationMissingOptionError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:162(InterpolationSyntaxError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:166(InterpolationDepthError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:177(ParsingError)
        1    0.000    0.000    0.000    0.000 ConfigParser.py:189(MissingSectionHeaderError)
        1    0.000    0.000    0.001    0.001 ConfigParser.py:203(RawConfigParser)
        5    0.000    0.000    0.000    0.000 ConfigParser.py:204(__init__)
        3    0.000    0.000    0.000    0.000 ConfigParser.py:211(defaults)
        3    0.000    0.000    0.000    0.000 ConfigParser.py:214(sections)
       11    0.000    0.000    0.000    0.000 ConfigParser.py:219(add_section)
       20    0.000    0.000    0.000    0.000 ConfigParser.py:229(has_section)
[...]
       10    0.000    0.000    0.000    0.000 {setattr}
        2    0.000    0.000    0.000    0.000 {signal.signal}
        1    0.000    0.000    0.000    0.000 {sys._getframe}
        1    0.000    0.000    0.000    0.000 {sys.exit}
        2    0.000    0.000    0.000    0.000 {sys.getwindowsversion}
        2    0.000    0.000    0.000    0.000 {thread.allocate_lock}
        1    0.000    0.000    0.000    0.000 {win32api.GetCurrentProcess}
        1    0.000    0.000    0.000    0.000 {win32api.GetFullPathName}
        1    0.000    0.000    0.000    0.000 {win32api.RegOpenKey}
        1    0.000    0.000    0.000    0.000 {win32api.RegQueryValue}
        5    0.020    0.004    0.020    0.004 {win32file.CreateFile}
       25    0.474    0.019    0.474    0.019 {win32file.ReadFile}
        1    0.000    0.000    0.000    0.000 {win32file.SetFilePointer}
        1    0.000    0.000    0.000    0.000 {win32process.GetModuleFileNameEx}
        2    0.000    0.000    0.014    0.007 {zip}

Using different runs, you can find out which method is called the most, which one it using the most CPU time and which one is the most expensive with profilers. Once you know that, you can start optimizing the sections which are the most problematic.

Once you are done with your optimizations, you have to run your profiler again with the new code and compare the results with the unoptimized version. That way, you can see if you are making progress or not.

I have come to think that while managing your code, you should use a separate branch for the optimized version and the unoptimized one. Since the unoptimized one is probably going to be easier to read and understand, it will also be easier to maintain that is a benefit you should keep.

Stop worrying about performance and enjoy clean code.