Programming Languages - Pour Quá?

Inevitably, in any discussion on new application development, the subject of using the correct programming language comes up.  Usually this comes in the form of "Use the correct language for the situation. Shortly following the consideration of this sage advice, comes a respectable statement along the lines of "it doesn't really matter what language we use, so lets use the one we are most familiar with". But is that really the best advice? Let's explore that a little.

In my discussions of the development of my personal project I am working on, I was simply not considering the language. For me the choice of Delphi was obvious but I was rightly challenged in that decision. Considering a language is not to be taken lightly, however there are usually good logical thoughts behind using a language the team is familiar with. Usually, the main programming language used by a team can do most things required, and the effort involved in learning a new language and coming to terms with its eccentricities would effect the project timeline and could threaten the delivery. For example, if a development team is to move to a new language there is not just the training involved, but the times when a developer spends a week or more trying to get something working as it should, only to find that those experienced in the language know to do that particular process another way due to some limitation or bug in the tools they are using. We've all been there. Add to that the current development still needing support in the old language.

However, the language used is a big decision. What of the market you are looking towards? Would the market require, for example, a Microsoft approach - i.e., best approach be damned, unless it's all written in Microsoft Visual Basic, we're not interested (shudder). Other thoughts may include any of the following:

Pure marketing heavyweight - Oracle (yes even Oracle Forms, still supported by Oracle, but no further development), and PL/SQL. Selling to large corporates, this approach ticks all the boxes and gets you past the elimination process.

Mature large development environment - J2EE. While I concede that every J2EE development project I have been involved in has been fraught with troubles and ultimately has not produced (although these issues can often be attributed to other factors), this does not limit the effectiveness of Java when managed correctly. Invariably developing a large corporate application in J2EE means dealing with numerous technologies and more than one programming language. I'm certain that others can cite many excellent large scale development projects using J2EE. J2EE however is the "expected" development environment these days and often companies will look for that environment as a mark of maturity in the supplier.

Medium scale development - C# perhaps? This environment is the favourite of those moving from Delphi or Visual Basic and has come to be a relatively well accepted development language well suited to Agile development teams.

Web development - While J2EE arguably dominates this area, Ruby for Rails is increasingly being considered for this environment. It is surprising how Ruby for Rails is still an unknown for many executives involved in technology decisions - aren't they the ones who's job it is to know these things? However the conversion rate to Ruby on Rails shows that it's general acceptance is just a matter of increasingly shortening time.

Small scale, Win32 development - Delphi, Visual Basic, C#, etc. Although it can be effectively argued that the likes of Delphi can easily be used (and I can cite many successful projects) in much larger corporate development projects, the acceptance for this is simply no longer there (shame on Borland).

While I am quite sure that you have your own list, and that you hold strong considerations that may differ from some of my comments, as a Development Manager in charge of a development team that creates corporate applications, the above is the way that I look at the world of languages. I'd love to hear of your experiences and thoughts.

Reputation vs The Resume

I have spent a good part of my professional career as a contractor so I was interested when I came across a post titled "Why bother having a resume?" on a blog site by Seth Godin. Seth gives an interesting argument that looks at the resume in 2 distinct ways: firstly he suggests that if you have a good reputation, then you won't need a resume; and secondly, that resumes are used by agents and employers in order to reject the bulk of respondents to get down to the interesting few they want to look at.

I partially agree with Seth on both counts, however experience suggests caution on either front. During the 1990's I was lucky enough to have so many offers for contract work that I could take my pick. Companies were falling over themselves to offer me a contract because I had the distinct advantage of having built up a good reputation in the IT industry here.

That no longer occurs, so what happened? Did my reputation go bad? No, I am still relatively well known and my reputation has not suffered. Did the job industry dry up? No again, although there are now many more applicants to choose from. The answer to this is much more involved and we have to look at a little history to see what went wrong in the industry here.

Prior to 2000, there was so much panic over the "millennium bug" that anyone who could spell IT was employed in the industry as a Y2K consultant - not much more technical expertise, or even very much in the way of IQ was required. Once the year 2000 came and went without the predicted worldwide mass destruction, the wonderful Y2K pig trough was taken away and hundreds of thousands of "IT Experts" were out on the street looking for new jobs. A short time later 9/11 hit the whole world (my brother was stuck in Hawaii, cursing that the late arrival of his plane from Malaysia meant that he had missed his connecting flight to be at a meeting planned for 9am near the top of one of the towers). Every IT project in New Zealand just suddenly dried up. This also meant that thousands more IT people, this time mostly good, experienced and employable IT people, were out on the street applying for any IT job available.

Companies and IT job agencies suddenly found themselves with a problem. For each IT job they advertised, they would get hundreds of applicants. Looking through all those CV's for a half decent applicant to consider was a nightmare. Companies that used to do all the hiring themselves, now started to put into place a "Policy". For those initiated into the secret language of corporates, a "Company Policy" is a proclamation that is set permanently into the steel frame girders of the head office and emblazoned across the foreheads of all General Managers and others who sometimes think they are in charge. This particular policy states, "No longer can a manager employ staff on their own but must go though an employment agency".

The reasoning was sound to begin with. Agencies could sift through the hundreds of applications and forward to them only the few that would be suitable for the role they wanted to fill. Reality however was much bleaker than the rosy view they were sold. What tended to happen was that the agencies, in an effort to cope with the influx of applicants, started hiring new, young people who were then tasked with the job of sifting the applications. I do know of agencies (or I should say "agents") who would, and still do, simply go through the first applications until they have two candidates that sound like they could do the job, then look no further (i.e. hundreds of job applications were never even opened), then forward those two to the client. Most however instigated the process of elimination that Seth talks about. This followed a simple process whereby firstly they would take out only those applications that had a university degree or higher, then go through those taking out only those who's current role was the same as, or similar to the role they are trying to fill. Only then, when they were down to a small hand full, would they actually look at the names and history of those that they had picked.

Even ringing the agents that I had built up a good friendship and reputation with was fraught with difficulty during the next 5-6 years. To protect themselves from the pleading masses, they had to resort to employing gate-keepers. These gate keepers would only let through people who were either the companies they dealt with, or the named people that had been selected from the process of elimination. The gate-keepers cared not for reputation and had heard before the pretentious arguments that they were somehow "long lost friends" of the employment agent in charge.

No job I applied for was going to even see my name unless by some pure fluke, I got through the process of elimination. My excellent reputation built with sweat and blood and now meant diddly-squat - the resume was king. Only of you were one of the first 20 who applied for the role, had a Masters degree from a known university, and had been doing that specific role for the past 5 years would you be deemed competent enough to have your name looked at.

Although the agencies have relaxed their stance somewhat, and I can again speak directly to the agent in charge, don't forget the power of the resume. Also don' forget the all important qualifications - even with my industry recognition and reputation I had to go back to university to gain qualifications enough to pass through "the process".

With recession noises being heard through the world at the moment, we may well find ourselves back in the worst of times again for employment.

Learning a new Programming Language

Just when I am deep into my evening programming in Delphi, I now have a need to take up yet another language as I take on some Perl skills at work. Its always a typical requirement for any programmer to have a few different programming languages in his/her tool bag. Currently I am working in Delphi, JavaScript, Ajax, Oracle's Application Express (Apex), SQL and others. I have in the past used such languages as Turbo Pascal, C and C++, TRS-Basic, MBasic and Visual Basic, C#, Modula 2, Perl, Java, Logo, PL/SQL, RPG, HTML (yea, I know, not really a language, but...), DataFlex, varieties of xBase (dBase, FoxPro, Clipper), Informix, OPL, Clarion, and no doubt some others.

Its always a hard slog learning a new language especially as you still have to keep programming in another language on a regular basis. With my work at home and my normal work, I will have to juggle a few languages as well as learning (re-learning) Perl. I used Perl for some minimal CGI scripting in the past but that was some 6-7 years ago and I really didn't get very deep at all. That's about to change. This will definitely impact my after hours programming for a few weeks.

So how do you handle learning a new language? To me that means studying; pouring over books, tutorials, and code; having bleary eyes; and getting really cranky for a while. Have you only ever needed to know the one language? After all, I can see where some Delphi programmers would never have needed to learn anything else.

Cooking code with the right ingredients

 

My previous post caused some very interesting discussions on the decisions that I am facing when starting on a new project. The suggestions were as varied as the choices in front of me. It seems that any of the alternatives can do the job, so why don't I just make a decision and move on? Because its at this crucial point that any choice I make will impact the direction of the application for many years to come.

About the only choice that is not under question is the development language of Delphi. Why? One person suggested that Delphi is dying and that we should all be using Ajax instead. Besides Ajax being a supporting web scripting language/tool that enhances JavaScript, the Internet is not my intended environment for the market I'm interested in pursuing. Oracle's APEX is a great development environment for that and with my recent experience in this it would be the obvious choice - if that was the audience. Delphi on the other hand is a very strong and proven development environment that can be as lightweight or heavyweight as required.

I have been involved in many varied software development projects using many languages and development environments. I can tell you from experience that 3 to 4 good Delphi developers can totally outperform 30 Java developers on a similar sized project by a factor of several months. I can also tell you that a lone Delphi developer can take on the big boys and totally capture the market.

But that's the tool, what about the ingredients? There has been discussion on InfoPower, TMS, and DevExpress components. I must admit that I know and enjoy InfoPower and I can complete the full development of the application before I have to purchase. The ExpressQuantumGrid Suite requires that I purchase it before I can even start to code with it. Much though it has been recommended, and indeed it does look nice, its out of the picture for my development. I simply can't afford to purchase it at this stage. TMS is good and I have used that before, however I still fail to see the benefits in most of the TMS components, perhaps I'm missing something.

InfoPower from Woll2Woll has had a lot of negative statements against it. One comment on my last post even suggesting that it looks a little dated. I thought that perhaps that's due to its demo screen dumps that try to show too many things with background images, interesting colours and an oversupply of fancy icons showing something less than professional looking. In reality I wouldn't use all the fancy background textures and some of the other features, but I would use the excellent usability features that their tools can give you. For example, simply by dropping a component on a form and setting a few properties, I can automatically create a full input screen with its own menu and imbedded controls.

I'll discuss the Firebird vs ElevateDB decision in another post. Both are very fine databases, both I'd highly recommend.

Back in from the cold

The time has come to return to programming my own application. I have been considering this for some time and indeed have made several false starts on this. Yesterday, I made a start on actually getting into the program again. This is not a work program, but my own application that I built and sold many years ago. It will be a long term, after-hours venture.

I've been looking at several tools for this venture. Delphi is a requirement as I can deliver a great application to the intended audience using Delphi. I've looked very seriously at both Firebird and ElevateDB as the intended database that I will be using. I still have not made up my mind on these yet as both have their strong points.

If I end up going with Firebird, then I'll most likely be using the IBObjects components. I've used these before at a customer's site and have been impressed at the genuine speed that results.

Either way, I'll be looking seriously at using the InfoPower components. Although they can be rather noisy (use a lot of network bandwidth), the intended audience for this application will enjoy the user interface these components can give them. Although I'd also like to take a good look at the ExpressQuantumGrid Suite, they don't offer anything but pre-compiled demos. It often takes a time using the component to decide if its as useful as the demos make out. Besides, I'd like to develop the application first before approaching some financial backers in order to purchase the components, complete the final programming/packaging, and get the marketing under way. Pity, it looks like a good product but I simply can't afford to purchase it at this stage.

ReportBuilder Pro will also be my choice of reporting tool.

You can be sure that I'll be looking at alternatives to the components mentioned, but these are my thoughts for the moment. Any feedback for this from you would be greatly appreciated.

Having spent my development time in the past year in such environments as Oracle, and Oracle's Application Express, although those are good environments, its nice to get back into familiar territory again.