Development Disaster
Mistakes To Avoid - Tips
In software development project, there are many mistakes that we can make that caused the project to be a disaster or ultimately a failure.
After years of involving in many projects, we would like to share some insights on mistakes that leads to software development disaster or failure. We can tell from our experience, a software development project failed are usually cause by mistakes of mismanagement and bad practice.
1. Involving too many stack holders
Especially in large companies where everyone wants to give their input to the project, ends up failing to get the essential requirements to produce a minimum viable product to begin with.
Requirements gathering has to be done by evaluating different scenarios for different problems. However when involving many different people, they always want their ideas to be developed in regard to whether it’s the best option or not, this is the cause of failure.
How can we avoid this issue? When dealing with large companies, we will recommend the client to form a task force by gathering one key person from every department. Hence, the feedback and inputs coming from the individuals of the task force will be limited only to modules/features that relate to their department.
After consolidate all the feedback and inputs, filter what to focus and which to priorities. Discuss with the project manager in detail and come out a plan on how to execute it.
2. Bad communication with developers
Communication with developers is the key to success for the project. Most of the time, the clients/management tend to assume simple few sentence of description on the requirements/issues the developers will be able to figure it out.
Information has to be clearly express and if possible to provide proper document that will help the developers understand the requirements, issue, and etc.
Example when reporting an issue should provide detail description on the issue, how to reproduce the issue, and if possible with screenshots or short screen recording related to the issue.
Another example, the project required a sign-up function, the client have to be clear on if it needed Facebook and Google to sign up integration, will there be an SMS verification (SMS One Time Password) or email verification? What sort of information will be collected during the sign up process, and etc.
Do not assume that the developers can understand what are the requirements and expectation without giving detail information about it.
Besides that, if the project only involve developers directly with the client person in charge, it's best to keep communicate clear and minimum as well. As there are no project manager involved to process the request from the client, calling, texting, meeting, these are all distraction to the developer. If the developers are currently already working on something, it's best to keep the communication minimum and when necessary only with clear intention.
If bad communication happens frequently, ultimately it might be the cause of failure for the project as it draw away focus, and cause mentally exhaustion.
3. Too complicated features and functions
Once come up with a set of features and modules, we have to make sure it’s simple enough for the users to use.
We have experienced simple features get so complicated due to the more ideas added to it which doesn’t have a realistic use case but makes it hard for the users understand the app.
This caused the development process to be overly complicated and harder to develop.
Our main goals should always be making things simple. Therefore, whenever are building the software requirement, always plan out the features and modules in a very simple way.
Take the hardest business case, break it down and simplify it. Do not make it any harder for the users. This will lead to a very high churn rate.
4. Frequently or never ending change of requirements
Having the right expectations of the final outcome is very crucial. If we are developing an minimum viable product (MVP) at a low or middle-range cost, then we cannot compare the outcome of the software with the top apps in the play store or App Store with years of improvements.
A perfect app or web to launch to the market is simply unrealistic, to make sure it adds value to the users and/or solves their problem. If it looks good and operates smoothly but does not add value to the users nor solve a problem, it will fail in the market.
There were times where our client would like to improve some of the modules/features and UI/UX of the web/app after finalize before launching to production, which takes additional time and cost.
No matter how hard we try, it’s impossible to create a perfect software product. Attempting to create a perfect app will always delay the launching and are usually not cost effective.
There are things we only learn after we launch the app. The courage to launch the actual product after a certain number of iterations is essential to move forward.
5. Having too many requirements at the beginning
For startup, we always recommend to start with an minimum viable product (MVP). Do not attempt to develop a big and complicated software to launch. It's going to cost a lot of money and time to do so.
For startup development, we won’t fully know the consumer behavior or the market properly. Therefore, the software has to develop in a way where it can be easily changed as the startup grow.
When the software grow and getting big, it’s going to be harder to change parts of it. It will take longer time to make necessary changes and will consume unnecessary costs which will hinder the startup as well.
6. Fail to understand what the user wants
Requirement gathering and preparing a project brief is a very important aspect of a software development journey. A small mistake in this might hinder the project at a later stage.
This process requires a deep understanding of consumer behavior, business processes, and business model.
Imagine finishing the development of a core module, everything is on track and suddenly a change in the core module is requested because an important aspect was left out during the requirement building which is also going to impact the other parts of the software. This is not only going to cost more time but since a big part of the codes have to be changed, the amount of issues/bugs which will come from this change is also going to be high.
Brushing out the specifications and requirements prior to development will ensure the development’s smoothness.
7. Not having a realistic expectation
Setting up realistic expectation is important, such as realistic on the timeline required to develop the software, making changes, perform proper testing, deployment, bug fixing, and etc. all tasks require times.
Do not expect any tasks can be simple and straight forward, as in software development, usually it's involving many different parts that work together to become a software. Thus any changes might or might not affect the original structure thus time required may be differ.
After the product has been launch, there might be bugs that we are unaware of, and usually require time to investigate on the issue or bug, then after figure out what went wrong, the develop will need apply a fix to resolve the issue or bug, then deploy to production.
There is no way to guarantee that the features and functions contained in any web pages / app screens or in a completed platform will always be error-free. Understand that the software are written by humans, and humans make mistakes. Even for big company software, after so many QA, QC, Testing, there are always bugs that are undetected.