Monday, 16 February 2009

Wood from the trees!

When I first picked up Delphi 1, I was amazed. I could kick up a decent application in no time. Prior to Delphi 1, we designed user interfaces on 80x25 squared paper. Delphi was that big a leap! I found it really easy. I was a Turbo Pascal programmer before Delphi, so the syntax was familiar. The RAD, drag and drop paradigm was easy to pick up and run with. I had it made.

So, here I was creating applications with an Object Oriented programming language and tool, therefore I was an OO programmer. Right? Well, the only classes my applications had were the form classes created by Delphi when you add a new form to the application. My first applications were a mess, multiple forms, with 100s of components stuck on then. I didn't know better. When anyone in those days demonstrated the power of Delphi, they would open a form, put a menuitem, a few dialogs and a memo, then they'd write a line or two of code, and voila, they had created notepad. Wow. I can do that I thought, and I did.

As time passed, and  moved to Delphi 2, I got better. First I moved all my database components to datamodules, but it was still a mess. No classes of my own to speak of, and global variables scatter everywhere. It was an improvement, but not by much. I was still writing procedural code. Moving onto Delphi 3, I discovered objects and classes. I ditched data-aware components, and learnt a bit about inheritance and polymorphism. I dabbled with interfaces, and started applying sound principles. Nowadays, I like to think I know what I'm doing, but still to this day I continue to learn. It amazes me that there is still so much to learn, but that's ok, it keeps it interesting.

So where am I going with this? Well, just because someone uses an object oriented language, it doesn't make them an Object Oriented programmer. The language, and the framework are just tools. It doesn't matter how good those tools are, in the wrong hands, they can cause havoc.

I've mentioned before in a few of my blog posts about the inexorable move towards .NET and away from Delphi at my place of work. I'm a lone voice in the wilderness pushing for Delphi, but when minds have been made, it's difficult to un-make them. One of the main reasons put forward by the .NET band, is that we'll find it easier to find developers if we ditch Delphi and go for .NET. It's true that each time we advertise for a Delphi developer post, we only get a few responses. It feels like we're scraping the barrel. It takes a long time to find a good Delphi developer. There's not many of us (notice how I subtly included myself in that statement!) Will it be easier to find C# developers? I'm sure for each post we advertise, we'll get 10s if not 100s of responses. Will they be any good? I don't know, but there will be a good percentage of them who, because they know a bit of C# will think they are .NET programmers. I think it's going to be just as difficult to find good .NET developers as it is to find good Delphi developers. We'll just have more CVs to throw away, and more interviews to go through, until we find the right people.

4 comments:

Anonymous said...

Well done.
Exactly what I see in my company.
I still do not see any productivity increase in the development team.
The only thing that has changed is that the number of programmers has increased, and the output is not yet as close as before.

Anonymous said...

Same problem here. I would rather take my chances with getting a good Delphi developer than getting an ex-VB now C# .net wannabe. The VB people were a misguided bunch to start with (CVs with JAVA / VB on them goes straight to the bin for a Delphi position - they were trained wrong and will just not fit in). Beware of the undercover C# converters who will code in Delphi but thinks you are more withit if you code in C# and then tries to convert the whole company.
Native code is the only way to go and I hate drag and drop coders. Use the best components out there to do things like TCP/IP,multicast,NT services and others but CODE the rest. NO DB-AWARE components, write a communication layer and NT-services (with no visual interface built in) to feed all data to clients.

I am raving about all this because of reading too many CVs lately. People are born to CODE, if you were not writing code by the 5th grade, I am not interested (Programming is a way if life, not a way to get money - that will look after itself)

Todays youngsters believe the world owes them something. Put in the hours! Work for 18 to 22 hours a day for months because you believe in the result (and love coding). If you were born to do it you will come out the other end SMILING!

Sorry, I live in a world where speed of code & databases is the be all and end all. (Trading systems for banks and broker-firms that connect directly into the London Stock Exchange).

Now CodeGear, get your backsides into gear and give us the most stable, multi platform, 64-bit, optimized for SSE1234, compiler out there. And get the ansistring handling faster than it was in D-2007.

Anonymous said...

I so totally agree with you. I've seen to much procedural code written in an OO environment, be it C#, Delphi or PHP, even in Java you'll find it. I'd rather be searching for a bright developer that wants to learn, like I've learned (and are still learning) how to do "proper" OO and will be open to peer review and learning a new language construct.

Anonymous said...

God but JP sounds so set in his ways. In my day etc etc