The application Microsoft Expression Web 4 is now available as a free download.

Download Expression Web 4

I only realized this when I was recently googling around for a suitable IDE for doing some web development. I had looked at a number of products, but hadn’t found any of them really suitable.

I tried out Aptana Studio which is an Eclipse based IDE. I don’t like Eclipse much anyway, although I know several programmers who think it’s great. Aptana doesn’t seem to offer any real advantages over using Eclipse with the plugins for web development.

I also had a look at NetBeans which seems a good environment for the serious Java programmer. But, although I like Java, I’m going to do web development for the traditional environment using JavaScript and PHP.

One of my favourite IDEs for web development is PhpDesigner which I bought a while ago. Although it’s called PhpDesigner it’s not just for development of PHP code, so its name is a bit unfortunate, but it’s a great application. It’s not free but it’s low price.

Most web development professionals use Adobe Dreamweaver, but that’s rather expensive just for doing a bit of web development.

JavaScript libraries

When using Javascript there are several libraries available, so that you don’t have to start programming from scratch.

The most popular of these is jQuery. I have also been taking a look at a library called Dojo, which seems good and is well documented. However, it’s almost essential these days that the IDE supports automated code completion (intellisense) and I tried to add this to Aptana studio, but it was out of date. Expression Web supports jQuery intellisense, but not Dojo intellisense. I tried jQuery intellisense in Expression Web and it worked straight away, so that’s the environment I’m going to use.

If you are interested in reading more, refer to my main page at www.garthwaite.info

Most companies develop their software in-house using a team of engineers. Your company should probably subcontract more of its development work.

Many managers like it that way; they can see whether the team members are working and they like the fact that their colleagues can see that the manager is responsible for a large team.

However, it’s often not an efficient way to work. The teams are often made to work in an open plan office (or cubicles in America) where everyone bothers everyone else, with conversations, telephone calls, meetings, etc.

It doesn’t have to be this way. Some of the work can be sub-contracted to engineers such as myself, working at their own premises. The contract engineer can then get on with the work each day, with no travelling time to work and few disturbances. Of course, this means that the work is judged by results, not by the amount of time, like a team member in the office.

The two major problems with software development projects are that they are often over budget and are delivered late. Large companies often accept this situation – but there are alternatives. If some of the work is sub-contracted, it’s possible to specify a fixed delivery date for each work package. The company also has more control over the costs.

There are a few preconditions for successful subcontracting:

• has to be a certain level of trust between the contractor and the company
• it has to be the sort of work which can be performed externally
• it can’t be classified (secret) development
• the manager has to be prepared to write a statement of work
• the contractor has to do the work
• the company has to pay on time

Visit my site at: www.garthwaite.info

Why software development projects go wrong

There are basically three types of software development projects:

• those which are a success
• those which struggle, but eventually come to a successful conclusion
• those which fail

This article considers some of the factors which determine where projects go wrong.

In my experience, projects often go wrong right from the very beginning. It’s rarely caused by lack of skills. Most software development teams contain highly qualified, intelligent people, but things still sometimes go drastically wrong. Let’s consider why this could be.

Poor requirements

This is probably the major reason why projects go wrong. If the top-level requirements are not correct, it’s almost impossible for a project to succeed. In some projects, it’s fairly easy to determine the requirements. In others, especially projects which are particularly innovative, in can be very difficult. There is a lot of skill required in writing good software requirements.

Some reasons why the requirements are sometimes poor are described below.

Not considering the needs of all stakeholders

The stakeholders are all the people who will have contact with the product in some way. It’s easy to completely forget some stakeholders. For example, the people who are going to maintain the product are stakeholders, so their needs should be considered from the very start. It’s necessary to get the stakeholders to state their needs themselves. It’s not sufficient that the project members or team leader attempts to guess the needs of the stakeholders, because they almost certainly don’t have the specific knowledge of each stakeholder.

Gold plating – over engineering – adding too many features

It’s a tendency of many engineers (perhaps including myself in the past) to add too many features to the product. Most engineers want he customer to be happy with the final product and it is often assumed that this means adding as many features as possible. This is often not the case – the customer would prefer something simpler, which is easier to use. Occasionally, the customer himself is to blame for requesting too many features. I’ve experienced this in cases where the customer is requesting technical bids from several companies – they keep asking the supplier to add new features, without increasing the price, with the threat that the competition will win the tender if the extra features are not added.

Other reasons are listed below

• Requirements which do not correspond to features the customer wants
• Making the requirements too detailed
• Mixing what should be separate requirements into one requirement
• Mixing requirement levels, e.g. mixing up high and low-level
• Missing requirements
• Requirements which are not implementable
• Requirements which are not testable
• Teams which are too large
• Giving programmers the task of writing requirements
• Adding more people to a project which is already late
• Not giving enough responsibility to individuals
• Performing “big bang” integration
• Not testing enough
• Unrealistic time scales
• Not taking the deadlines seriously