What common mistakes one should avoid during Software development?

The challenges faced by someone building a three-month application are quite different than the challenges faced by someone building a one-year application. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hurts developer morale and productivity.

Hi

Based on my experince in working in different types of technologies, the mistake may vary from each other.

1. Defining the scope

2. Review Process - REquirement Document, Functional Document, Techanical Document, Test Strategy, Test Cases

3. Setting the expectation and visibilty to all the team members

4. Regalur status updates with all the team members , the frequency based on the criticalness of the project to the comapny

5. Better interaction between the testing team and the development team (one view, one requirement)

6. Better interaction, process, audit checks by Qaulity assurance team

7. Define a realistic schedule and commit

8. Sometimes we need to say "no"

9. Knowledge transfer between onsite and offshore team members

10. Define and manage the risks (biggest problem lies here....)

11. Take the help of the senior management up front

12. Give visibilty to customer/client at all the milestone and have a informal understanding, so we do not have a shock at last moment

13. Comments on all the codes

14. Single source of truth (all the documents should be in one place with updated version) for everyone

15. Tools - Project Mangement Tool, Configuration Tool, Assest mangement tool, etc...

16. Have a proof of concept for imnportant design requirement or critical requirement

17. Product Development/In house product development - the best process/practise must be taken for the product development, avoid customization as much as possible\

18. Commuicate the understanding of the requirement, process, or important steps via - Use Case, Proof of Concepts, IDEF, Process Flow, High Level Test Case Flow, etc...

Many other attributes to are there as discussed by every one.

The basic problem that is seen with indian IT companies is not having a spent right amount of time for project management. If we do good project management we should be able to come up from these common mistakes.

According to me overestimated savings from new tools or methods is also a big mistake which one should avoid. As organizations seldom improve their productivity in giant leaps, no matter how good or how many new tools or methods they adopt. Benefits of new practices are partially offset by the learning curves associated with them, and learning to use new practices to their maximum advantage takes time. New practices also entail new risks, which are likely to discover only by using them. We are more likely to experience slow, steady improvement on the order of a few percent per project than you are to experience dramatic gains. A special case of overestimated savings arises when projects reuse code from previous projects. This can be a very effective approach, but the time savings is rarely as dramatic as expected.

If you not get the client approval URS (User Requirement Study) then the software development process going on and on.

You do some changes and client not approve it and you have to do it again.

The programmers and software developers usually end up developing Ad-hoc applications and software.

This may be mainly due to the limited resources and less time deadlines which eventually allows programmers to only make Ad-hoc applications. Such applications result to have low flexibilty, and they seldom contain future expansion scopes.

This also results for the softwares to be less cost-efficient.

Programmers should work with the analysts of the firm for which they work and should come up with better flexible applications that can be greatly altered and modified according to the firm's future needs.

Such information can be better provided by analysts. The firms should also encourage the programmers and software developers make such cost efficient programs as it is greatly in the companies favor itself.

Many companies that i have worked with have and still allow the developers to make most of decision, when it comes to adding features to a software App without consulting end user or client. Assuming that would be great feature. Like the saying goes Assumption is the mother of All F$%#@ :)

apart of the things already listed, a few more things that were on top of my mind :--

1) not having clarity about requirements [many a times i have seen this as the main culprit]

2) how the system that you are building is going to ineract with other systems [the analysis part is missing]

3) i think its also the lack of time spent during phase as it goes dierctly to the number of defects in the UAT phase

at times poor planning and insufficent funding by clients also adds to a devlpoes misery though

Vinay

1. Unuseful: project should provide end user requirement, for example POP3 main access is not free in many mail systems but in GMAIL is free, well users use Gmail

2. non-friendly: may it's not important for a developer like you like me, but for a simple user it's really important how page is interactive?

3. non-powerful: system should be accessable and be ready all the time, never send any Error or exception, it's really important may with a very non-important exception or error, user will remove own account from systems

4. platform depend: the system should be platform independence, the C# won't be a cool platform for a enterprise project,...

in fact many factor is here but all of them point to a simple user, we should do any thing to stay users humor

The project exists just because of the requirements. Projects need to ensure that they have a reliable, knowledgable and acknowledged expert team/person in charge of the requirements analysis and documentation. Most project I know of fail to gather the requirements in a usable form with clarity and continuous focus on removing ambiguity from the requirements. All work on the project must be eventually, clearly and unequivocally traceable to a requirement.

I would consider the classical mistakes to be improper definition of Scope - based on which the estimation and project management are done.

Estimation - there is never an agreement even amongst the best estimators on what the actual estimation is - all due to improper training and limited understanding of the intent and lack of customer focus.

Change Management - it is natural that changes will occur. But improper management of these changes can prove to be very costly.

I think due to excessive multi tasking they are not able to handle risk i.e.Insufficient risk management. If he is  not actively manage risks, only one thing has to go wrong "the project from a rapid-development project to a slow-development project". So, failure to manage risks is one of the most common classic mistakes.
Another mistake can be Shortchanged quality assurance :-Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating test planning, and performing only perfunctory testing.

It is inevitable that during large software developments that chnages keep coming till the very end, no matter how well it is planned. So some of the following care should be taken

1. Always parameterise whenever there are debatable options or choices or conflicting requirements are possible 

2. Always avoid hardcoding and deal with variables

3. Always test at every smallest runnable piece of code is completed

4. Document Judicicously - Avoid excess documentation and at the same time make sure required documentation is maintained at that moment 

It is always better to analyse the full impact of the system. Changing /modifiying code in part will always lead to problems. So it is always better to take considerable amount of time  for analyzing the system before modifications.

As I am still rather new at software development, I am using Microsoft Visual Studio 2009. I have found that although I have made a few mistakes, I have not found any other problems as yet?.. How can I help you?

I agree... Totally!

Mostly when the project is started, it has a tight schedule with client sitting on top and supported by the managers. Many a times, the management tries to put too many resources just to speed up the job which is getting done. The issue here is most of the resources that come in this kind of environment likely are developers with mid level or junior level experiences. Now they just start developing with a little time to think and reflect on the design aspects. The key here is to have a robust and scalable design ready for the application before really jumping into its realms. The design should be given extra effort than coding as it is the most crucial part. In fast paced development, almost all the times, this aspect remains neglected. I would suggest give at least 60-70 % of the total time in design, your development will be much smoother and will have less bugs. By design i Mean, Arch, HLD and LLD.

Once the design part is done, then comes the most critical issue. Too many people trying to get in charge of too many things. As rightly said, "too many cooks spoil the brew", thats excatly what happens here. During flat hierarchical development process, we tend to lose sight the product and try to get into "who's incharge" frame of mind. This is very crucial in the mid stages of the project. One has to continously keep a watch to it. 

Lastly i would say, lack of proper technical manager. Mostly these days we see more of people manager and less of technical managers. Their commitment to the client is not based on the feasibility of the solution. Rather it is more to do with figures. The commited dates might not be feasible for a developer to complete the assignment. but still the Dates remain commited. The developer stretches and somehow manages to give the code, whcih is less of quality and hence reliability. Instead, if the manager doesn;t have too much of hands on technical, he should discuss the feasibility with the technical architect and then give any commitments.