written by owen on 2012-Aug-21.

The problem spans the gamut of interactions between the people that help to build the software and the people that want it. I will try to do a broad phase attack on all the possible problems that can arise in the development process in no specific order. While these may not occur in all cases and will certainly not prevent the completion of the project - they will certainly turn a 3 month project into 2 years, easily before any one of the affected parties even realise it.

Project Managers

Project managers will produce requirements in such a way which actually hinders the project development process. You can see the traits of a bad requirements when sections of the document are constantly being added and/or revised throughout the length of the project. Many cases project managers are often unaware of the code, SQL, the effects of many-to-many relationships and fail to consult the programmer/analysts on key technical details in the requirements gathering stage. Take large amount of time to compile basic, incoherent and incomplete surface requirements. Mandate complicated module tests to be done by the same people doing the programming in the hopes that it will prevent major bugs in the future. Define incorrect or underestimate incorrect timelines for project completion while making changes to the program requirements in the middle of the project. Failure to keep the project in scope, monitor progress and inability to identify problems in the requirements. Mandate, suggest or purchase tools/policies/procedures which they have no technical knowledge of, are inefficient or overly complicated in the hopes that it will make the project successful.

Programmers

Often misjudge their competence. Lack of fore-sight. Write code without considering the effects it will have on the rest of the present system or the future maintenance. Often use platforms that they have no control over or do not fully understand. Framework and OOP junkies who often use the wrong tools for the job and copy paste code from the internet. Operate on the bleeding edge of technology without considering the trade offs and additional requirements. Eat thier own dog food - create APIs for themselves that no one will ever use. Poor communication skills - if a problem is discovered in the requirements, the programmer tries to hack around the problem instead of mandating a change to the requirements. Failure to inform the project manager that the train is derailed. Also in some situations there is the problem of Tunnel Vision in the case where they fail to consider alternative to thier prefered solutions, spend too long focusing on non-critical features.

Business Analysts

Often compile bad requirements from clients and fail to manage the clients expectations. Believe that the programming is the easiest part of the process. Attempt to replicate real world processes in the virtual world by mapping them into table designs without considering that software has benefits over real world process flow. Have no idea how many tables are in the database - NO FREAKING IDEA. Are satisfied with not knowing anything about the programming aspect of software development. Failure to identify the real reason why the software is being developed and blindly add requirements as they arise.

Clients

Often clients never use the software they request and have no experience being on the user side of the problem. Clients often make requests that are impractical to develop and require hundreds of extra hours of programming. Clients often request many-to-many relationships. Have no experience in human interaction design, human resource management, fail to get outside opinions on things they are confused about, ask the wrong questions and never follow up on project progress (before, during and after). Are cheap and will attempt to request more work in less time for no additional cost - read up on laws of the thermodynamics. Are often unaware of what actually happens in the software development process.

Directors

Will request changes to all the primary keys in the database so that it matches a spreadsheet document. Or in the worst case request a summary report of every entity in the database on a single report ad-hoc.

Conclusion

Certainly there maybe many more ways in which a project run off track and many successful companies are some of the most in-efficient cargo cult shops in existence. However such is the nature of software development and design, its a fuzzy art, there are no magic bullets/apps/techniques to avoid the time factor. Time is unavoidable. Time is money. You cannot defy the laws of physics especially the laws of thermodynamics and conservation of energy. The most you can do is plan well, learn from past mistakes, avoid over-planning and try to keep focused on the major goals of the project. Figure out what works and avoid marketing traps. You can always make suggestions in the comments.

permanent link. Find similar posts in Articles.