Moved Again

Just a quick note to let everyone know that I have moved again.

I've taken a position of Applications Development Manager for a good team in Melbourne Australia. Once I have settled in, I'll take this blog up again. In the meantime, please feel free to talk amongst yourselves.

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.

Team Collaboration Software

We're shortly to turn our attention towards team collaboration software and I'd like your help in the search.

I 've had some excellent feedback on my series on issue/bug registers with some wonderful suggestions, some unfortunately far too late in the process to enter into consideration. I'd like feedback now on team collaboration software.

Since we have settled on JIRA as the issues register, we are seriously considering Confluence (http://www.atlassian.com/software/confluence/) but there are others out there.

The following is amongst the items we's like to see:

• Document version control - at least see that there have been previous versions of a document that we can look at. We'd like to see documents stored either in some sort of Windows-type folders, or perhaps attached to some Wiki path, but we'd look at other suggestions.
• Wiki - we have sales-types in the organisation, they don't do Wiki very well so it's got to be able to be used with MS Word or Excel - and if they load a document, make changes, and save it - the Wiki or document MUST be updated, not just the temporary file that's created on the user's temp directory.
• A discussion forum would also be nice.
• able to add graphics to documents
• Able to add new fields to fill in, .. perhaps
• Able to see when and by whom something has been changed
• It would be a HUGE plus if it was able to be run in Unix. In fact, it would be a negative we'd have to get around if it was only Windows.
• Accessible via internet/intranet
• Lightening fast search for a word in a gazzillion documents, including Excel, Word, PDF, etc.
• Secure

 

So if you have any suggestions on products that I can look at, then please let me know.

Tools for the Development Team - JIRA

  

Crikey, where did the time go?

This has been a very busy time for the team with a large number of projects and small alterations coming through as well as RFIs and RFPs (Request For Information / Proposal) to answer. It is at these times when a good issue management tool proves its worth and certainly ours did.

I've talked a lot about the different tools that we've looked at here, but we did finally make a decision, the winner was JIRA from Atlassian (http://www.atlassian.com/software/jira/).

So what was it about JIRA that made it stand out against the, sometimes free, competition? It does what it does well.

Many of the other programs that I looked at tried to do many things, and in my opinion, sometimes meant that it did none of those very well. JIRA doesn't suffer from that. It knows what its supposed to do and it does it well. That's where the final decision lay as far as the team were concerned.

Getting to know JIRA.

I had used JIRA in the past so it was second nature to me, but not yet to the team. There were a couple of language constraints that we had to get past before some of the team could understand the concept. Everything you place in JIRA is an "Issue". It doesn't matter if its a suggestion, a bug, a task, whatever it is, if its in JIRA, then its an "Issue". This is one of the very few things that I could not change in JIRA.

The other area that new users will enjoy getting used to is that nearly everything in JIRA is configurable. At times it seems that everything that is asked for is there within the configuration available to the JRIA Administrator. You will get to understand how such things as Notification Schemes and Permission Schemes work, and you can assign different schemes to different projects.

Projects

Users or Administrators (depending on what rights the Administrator gives each user or user group) can set up Projects in JIRA and create Issues to the projects. A Project can be either a standard project with a beginning and an end (e.g. a software development project), or an area we can place tasks for normal things needing to be done (e.g. an application or "IT Admin").

I have set up the Notification Scheme so that users will get an email when they area assigned to an issue or when someone has added a comment to an issue that is assigned to them. You can set up notifications as you wish. Users can also "watch" particular issues and be emailed whenever anything changes. You can even email JIRA to open a new issue or add a comment and email attachment to an issue.

Issue numbers are related directly to the project via a 3-4 letter prefix. For example, you might have a project called "IT Administration" and a project called "Worldwide Enterprises Project", which will have a prefix of IT and WWE respectively. Issues in IT will start IT-1, IT-2 etc. and issues in WWE will start WWE-1, WWE-2 etc. so it's easy to know what project an issue relates to. You will find the team with a new vocabulary of words like WWE-193 and IT-22 arising in every sentence.

Users can log work against issues and time tracked.

Workflow

The Enterprise version has a number of tools that allow you to create and change the workflow, however we opted for the standard which uses a good workflow.

With the standard, an issue is Open when it is created. Once a developer starts work on it, they can change it to In Progress, unless its a small issue that is completed in less than 30 minutes - they can then just go straight to Resolve.

I have set it so that only myself and QA can Close an issue, but anyone can Reopen it for any reason.

Issues are never deleted, only closed.

Issues can be Resolved in a number of ways and the user is presented with the following in the Standard JIRA, the other JIRA versions allow you to add to or change these :

• Fixed (default) : A fix for this issue has been completed to the satisfaction of the user
• Won’t Fix : The problem described is an issue which will never be fixed (e.g. the issue relates to a previous version and the workaround its to upgrade)
• Duplicate : The problem is a duplicate of an existing issue (user can link the issue to another)
• Incomplete : The problem is not completely described. Used only if the creator of the issue cannot supply any further information (i.e. the creator is no longer available or all attempts to contacted have failed).
  Normally, if the problem is not described correctly, it is up to the user to reassign the issue back to the creator with more questions as comments
• Cannot Reproduce : All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behaviour would occur. If more information appears later, the issue may be reopened.

Searching

Users have two ways that they can search for an issue or comment.

"Quick Search" is a seemingly insignificant little search box up the top right of the screen that is extremely powerful. Type anything into there (like "VPN Connection") and JIRA will do a very fast search of all its issues and give you a list of all issues contain that word or phrase. If you know the JIRA number, just type it in and you'll be taken directly to the issue.

"Find Issues" is a menu item that allows you to find issues by creating a Filter. Filters can be created on the fly, saved to a name (e.g. "All Unresolved Development Issues"). JIRA will automatically add a Filter to show you all issues currently assigned to you.

Setting up these Filters is a simple idea of selecting from the list of selections for the fields to search, for example, selecting 1 or more projects to search. Other areas in this search is the Query on the Summary, Description and Comments fields. Query is a reasonably powerful search facility explained Here. Date and time fields have the ability to enter either specific dates, or relative dates (within the last x hours/days, in range from/to). This allows me to, for example, set up a filter to report on all JIRA issues created last month (don't tell my boss that my monthly management reporting is that easy).

When you activate or view a Filter, it shows in a list that you can scroll through and export to Excel or Word, and

Filters can be set up to appear on your JIRA Portal.

The JIRA Portal

The front screen in JIRA can be set up differently by each user. You can add, delete, and move items around the screen to suit yourself. You can add Filters that you created yourself and add pre-set Portlets. These include such things as Project Stats; Admin functions; Filter Stats; My Watched Issues; and Issues in Progress. These can be arranged as you like with the most used Portlets showing at the top of the screen.

My own Portlet shows some details about projects; lists all my save Filters; Overdue Issues; Issues update within the last 8 hours; Resolved issues awaiting me to Close; Issues I'm watching; My assigned issues; and a few of the available graphs that I got from a free JIRA Plugin available from the Atlassian website.

Using JIRA

After using JIRA now for a few months I can honestly say that I have resolved a number of team issues here. I know what is happening; what the team is working on; issues are tracked and comments are added as new information comes in or things are done; the developers and BA can fully understand issues with a place to keep documents, screenshots and comments; work can be prioritised; and everyone can see what work lies ahead of them.

Nothing gets forgotten; work is logged against issues; issues are assigned to others where necessary within the workflow; and management reporting is completed.

The Down Side

Of course there's a downside -  it costs real money. JIRA comes in Standard, Professional and Enterprise editions costing US$1,200, US$2,400 and US$4,800 respectively. While I would have loved the Enterprise edition, we are getting by quite nicely on the Standard edition.

You will have to keep on top of it when you first install it as there is a mind-set that says "I've assigned this issue to someone else, it's no longer my problem". It's also easy to simply ignore issues assigned to you and then get upset when you have hundreds of issues in front of you.

Summary

As I said, "JIRA works". Sometimes it comes down to that. As a Development Manager I can trust it, the developers trust it, and everyone in the company trusts it.

Try it out for free on your server for a month or two. They'll extend the free trial if you ask them nicely, but I don't think you'll need it. It's so nice to find nice people who actually support and use their product themselves.

 

Just a quick note: I have no affiliation with JIRA\Atlassian . I don't know anyone there and I don't get anything free from them .. although a tee-shirt wouldn't go astray (HINT HINT Atlassian - Grin).