Things You Should Never Do In A Software Project

Branching

Its when different branches of your code have different features. Problem comes when you built on features on basis of work already done in other features. Then when you need these new features in other branches you lack that basic work which is necessary. As a result you have to almost have those features in the branches, which means doing the same work over and over again.

The solution is to move on a single branch, adding features as needed. Then use end-user administrator-level configuration to turn off features that are not needed.

Finished but Unreleased Features

Once a feature is completed and appropriately tested, it should be released. Piling up features to be released in the next mega version is a waste.

The solution is to use sub-version to release less important features.

Having Multiple Owners

Owner here means administrator, that is, a person who is responsible for the project. There have to be exactly one owner of the project, who is fully responsible for the progress on the project. The person who initially started the project is also usually the person who done most of the base work, such as building the underlying engine/kernel, and is also the person who took many critical early decisions about the project such as what technology to use, what platform to support, what architecture to follow and what libraries to use. This person is naturally the most appropriate person to own the project.

No matter how large the project is, and how many hundreds or thousands of programmers are involved, the owner have to be one and only one person. This is the person whom you expect to be the first to go the extra miles for the success of project even when not asked. Its also the person who is brave enough to handle wrong decisions of management often by forcing a reversal.

Throwing In Extra Men On a Delayed Project

This never works. If a project missed deadline then adding new personnel to the project make it to be delayed further than in the absence of them. This is because software development is such a hi-tech job that new people requires project-specific training and there previous experience not help much.

The solution is to make the same people continue work on the project that are already working on the project. If the initial staff is no longer available, then its ok to have a fresh team but thats a separate thing and is a valid strategy irrespective of delay state of project.

Habitually Forcing Programmers to Work Extra Hours

While its ok to force your programmers to work extra hours, especially near release date of project, its a bad idea to make a habit out of it. Tired mind produce buggy code, because the components are not well-tested before they are relied on, certain shortcuts are made here and there, the approach used is too specific to be used elsewhere in project etc.

The solution is to allow programmers go home at end of day. Ofcourse to stay in profit this implies that you have to be very careful when hiring programmers to have only the skilled ones so they do not take undue advantage out of this strategy.

Avoiding Static Code

Languages have the feature of static methods for a reason. The methods that work ONLY on the sent in parameters are supposed to be static, because they do not depend (i.e. use) any object or global state. Examples include encryption, hashing, DAL used with stored procedures, selecting last item in dropdownlist, returning an array of values of items selected in a multi-select dropdownlist etc.

There are enormous benefits of static methods including having a ready library that can be used in other projects.

Static methods are anti-object-oriented because they defy architecture. In a sense they lie flat in the highly structured OOP environment. This is a good thing because of three reasons:

• You do not need boiler-plate instantiation and initialization code of building object graph before they can be used. Instead you can use them directly.

• Changes in class hierarchy structure do not effect them. So this is one less place to test and solve bugs when such changes happens.

•  They can be used in other projects which have different class hierarchies. 

These methods are inherently thread-safe because they do not depend on any state.

Having Noisy Environment Around Programmers

This reduces efficiency because programmers tend to slow down while keeping in mind workflow of a group of variables they are currently working on. Other problems include poorly thought or poorly implemented architecture, buggy code and resignations.

For a programmer, a silent environment is marginally more important than even proper cooling and furniture and is hugely more important than salary.