Friday, 20 February 2009

See what I mean?

I recently posted about the difference between developers and good developers. The point I made is being confirmed to me on a little application I've been asked to have a look at. The application in question is written in Delphi, by someone in the organisation who is not a developer. I knew this before I saw the code, but I can confirm the fact now that I have.

This is what happens when you have someone who thinks How hard can it be? That's the problem with Delphi, it makes it look so easy. And it is very easy to write your Hello World applications. In my opinion, it's easier than .NET (although that is not too hard to get started in either)

The problem is we don't have enough Delphi developers. Someone needs a small application. It's one form, spread over two tabs, less than a weeks work. All developers are tied up, and the conversation goes :

Manager 1 - Didn't Joe do some VB programming a few years back?

Manager 2 - Yes, I believe he did.

Manager 1 - Jolly good, get him to write that new application we need.

(The names have been changed to protect the guilty)

That's where the problems started. When it was ready, the testers noted there were a lot of bugs, and the more that were fixed, the more cropped up. That's where I come in. I have to try and salvage something from this mess.

So what do I have? A small application with a lot of Access Violations is what I have.. Some when you start it up, others when you press certain buttons, and a few more when you close it down. I had a quick look at the code, and found that while the developer (and I use the word in the loosest possible way) seems to know about classes and objects as he/she has created a hierarchy of classes, he doesn't really understand it. It's not all drag and drop (oh how I wish it was) It goes down hill from there. He/she has evidently not heard of encapsulation. All variables are exposed as public (glorified globals). Forget polymorphism, and someone forgot to tell him/her that Delphi has no garbage collector. Mix all of that together and you get a mess. Most of the time he/she has made no attempt to free objects. A few times, he/she has tried, but thought that setting an object instance to nil would do the trick. variables are declared (publicly) in base classes and then created when needed. Sometimes multiple times, thus leaking memory like a sieve. I could go on and on, but I don't want to cry and short my keyboard.

So would garbage collection have made a difference? Not really, it would still have been a mess, just a different type of mess.


Anonymous said...

Classic example of a little knowledge being worse than none at all.

Anonymous said...

No idea about memory management, that's a typical Visual Basic programmer for you. I have seen lots of that. VB actively encourages this kind of programming. But since setting something to NULL actually does free the object in VB most of the time this is an easy mistake to make.

I am just glad that I don't have to use this poor excuse for a programming language any more.

Anonymous said...

I have seen this all too many times. Most of the applications I am asked to maintain suffer from poor design and coding practices. These "developers" are all too often people who write code as their career (usually juniors). Unfortunately many managers don't understand the difference in value you get by hiring someone at $60/hr. vs. 25/hr.. Heck a drywaller gets paid better than some companies want to pay their developers.

Even when the product becomes an unmaintainable mess, they want to cheap out on fixing it rather than doing it right, and eventually the whole effort fails miserably.