5 mistakes to avoid in software development projects
Not having a well defined methodology. Would you attempt to build a house without following a specific set of rules, best practices and sequence of tasks? Then why so many development shops think they can just through 5 or 20 developers into a room and let them decide how to approach the project without any clear direction and methodology? Introducing methodology from day one is the most important success factor for medium to large projects. So please, don’t accept “we’ll get to it later” or “we don’t have time to introduce a methodology right now”. Stick to your guns and insist on clearly defined methodology if you want to improve chances of success.
Not sharing the big picture with all members of the technology team. There are two important reasons why everyone should understand the big picture. (1) Does anyone really think that hundreds or thousands of chunks of code built in isolation can be linked together and produce a coherent software product or application? Think again. (2) Understanding the big picture makes people feel more important and more in tune with the overall goal. Developer retention anyone? A developer is not going to stick around if he’s just pushed into his cubicle and not allowed to express opinions and contribute at more than just the “write this function” level.
Not having a tool for tracking projects, tasks and bugs. We’ve all used spreadsheets and word documents in the past to keep track of requirements, projects, tasks, bugs, etc. But that was 1998. Well, It’s 2012 now! Just do some research, select a tool and use it. It’ll save teams ton of time and make the process much easier and less risky. I can’t believe some shops still use the spreadsheets.
Not having well defined coding standards and not conducting code reviews. Yeah, this one (or two) is important. Try telling a new developer to fix a problem when the original developer is no longer there and the code is just plain ugly and incoherent.
Not having a person or team responsible for overall architecture. It’s like building a house without a blueprint. Enough said.