Common Software Risks that every developer Should Know
From the beginning to the deployment in production
In this article, we are going to talk about the typical mistakes we usually make from the moment we meet with a client to develop their product until the moment the product is in production.
These are some of the reasons why a project does not meet the client’s expectations:
- It takes more time to develop the project than agreed.
- The project doesn’t satisfy his needs.
- The project is more expensive than the accepted budget.
- Our application does not scale well.
First, let’s start when we meet with the client.
With the client/user
The first and most important thing is to know what we are going to talk about, define a maximum time for it, and if more meetings are required, or they ask us to indicate how they can do something we will charge them.
It is not the first time that a client tells me his problem, and after giving him an idea about a possible solution, he hires another person (cheaper) or uses his development team for implements the solution I have proposed.
Result: I lose my time.
Everything seems easier than it is
Business people consider their requests to be very easy to implement, and they often don’t understand the complexity behind what they think to be simple. Others, before you even do an initial analysis already, they claim that in less than a month, you will have it done.
They don’t know what they want
Another big issue with them is that they often need to solve a different problem than the initial request.
Most clients or users don’t know what they want until they see it. Most of the time, it is not until they start using the Software when they realize what they need. In consequence, requirements continuously change throughout the development process, so be careful about giving a deadline.
Errors from misunderstandings
Errors also result from miscommunications or misunderstandings between the client and the programmer. Some things may seem entirely logical for you and vice versa, so don’t start the project until you know what you have to do.
Communicate with the client as clearly as you can and as often as you can, preferably in person or by phone/video call. Show him sketches or prototypes of what you are going to develop next days.
And remember, Using email is usually not a good idea.
Trying to solve all the world’s problems
It is common for the client to want the application to do all sorts of things. Help him see what the minimum he needs to be able to solve their need is.
In your team
Get to coding very soon
Start too early to code, and not asking for feedback until the end is probably one of the most frequent mistakes.
Agree on a short cycle of iterations with the client/user and show them every week or two that you have implemented the right solution for this. This is the best way to check if we have understood what they have told us (or if they have understood it) and if we are doing well. Developers don’t dare to say they don’t understand the requirements.
Sometimes for fear of looking bad in front of our boss, client, or our co-workers, we don’t dare say that we haven’t understood something, and this, in the end, results in a waste of time(and money) for everyone.
Too much pressure
Too often, the business puts tremendous pressure on the developers to deliver the solution too early without letting them no time to think of good solution design.
Poor quality
Without proper planning and when a lot of pressure is put on the developers, they start programming without testing, so in the end, the Software that is delivered is full of errors.
Be too proud to admit that we don’t know a framework or tool
If you don’t understand something or don’t know how to solve a problem, ask for help as soon as possible. No person knows everything, and it’s okay if we don’t know how to do something. Request a colleague for help or make it clear that you will need some time to form.
The use of tools, methods, and technologies or build systems outside our typical domains/experience is a risk if we don’t have the proper knowledge.
Delegating too much to frameworks
Using frameworks without understanding very well how they work or without the basis on which they are based is another way to ensure a low-quality software and with problems in the future that we will not know very well how to solve.
Also, it’ is a good idea to avoid the use of magic boxes to solve something.
Technical debt
We often believe that a project has an end where nothing will ever be done again. This rarely happens, and it is likely that after some time, we will have to modify it because the client wants to add new functionality or modify something. If our code is not solidly built and it has a lot of technical debt, any new feature will be costly for us.
Inconsistent Software
The Software that works correctly in one environment but in another no works or works differently, for example, a Web App that works in Chrome but not in Internet Explorer.
Make sure to make it clear at the beginning of the project where your Software will work.
Using too new Technology
Using very new and unestablished Technology can be a big problem in the future. Security risk or maintenance risks in the future are two good examples.
Remember that many of the newest ideas and frameworks offer only the essential features, and maybe in a few months, they won’t get updates anymore.
Also, working on the technology edge can cause your team to make more mistakes and create significant safety holes.
Using Outdated Technology
Outdated Technology can be expensive to maintain and can decrease team productivity. It also can increase the security holes. So try to stay up to date but use established and standards technologies.
Multiple developers and subcontractors
Develop complex software witch multiple developers or subcontractors can be hell if we don’t plan well, and the obligations of each party aren’t established from the beginning.
Failure to handle production data capacities
This refers to the Software’s incapacity to process the level required by the organization. Test your product with a real number of requests or volume of data.
Conclusion
In my career, I have made almost all these mistakes, especially at the beginning, and they have given me more than one headache to the point of ending up badly burned. Luckily I have learned over time, and now I enjoy developing Software.
If any of these things help you, I will be satisfied. Thanks for reading me!
Any other ideas?
