top of page
  • Writer's pictureSuris Code Team

Classic problems in software development

Software engineering is a discipline that has undergone years of improvement. Over time, specialists have collected experiences and lessons learned from millions of projects and teams. Here are the main problems that a software development project may face:


1. Unrealistic time estimation

Making a good calculation of the resources, time, and costs required to carry out the project is a task that is sometimes not approached in the right way. No one wants to hire a service with a certain budget for time and cost, only to find out that it will actually take twice as long and costs will multiply.


Although estimation is largely a process based on experience, there are also techniques to get fairly close to a good estimate. Therefore, setting realistic expectations regarding these two topics, thanks to proper planning and analysis, is crucial.


A technique that allows us to have an idea of how a project was estimated is to check the following:

  • Did the provider have meetings with me to conduct a previous analysis?

  • Did they contact me to resolve any doubts?

  • Did they request documentation to help them estimate?

  • Did they express what I need, as to verify if they understood me?

If any of these points were not present during the process, it may be an indication that your project has some risk of not being well estimated and quoted.


2. Incorrect risk management

It is vital to perform a good analysis of the project risks and actions to mitigate them, so that the work plan is not stopped or delayed by unforeseen risks in the analysis. It is then necessary to identify at least known and predictable risks, whether they are related to technology, people, context, market, competitors, and/or government, to be prepared with an action plan in case any of the identified risks occur.


Doing this planning exercise allows us to align expectations to be more realistic, depending on the possibility of certain risks happening and their criticality. If many risks with a high probability of occurrence and criticality are identified, it is necessary to establish a broader action framework. Conversely, if the probabilities are very low and their impact is not very high, then the plan can proceed as estimated.


3. Insufficient quality control

Quality assurance is a fundamental stage in your software project, as in this stage, all critical and breaking points in the operation of a given business and towards which the software is aimed are validated.


It is recommended that at least 30% of the total development time be allocated to the tests that the quality department performs. Estimating a shorter time is not advisable, as according to experts, it cannot really be guaranteed that the software can perform everything expected correctly, even when the functionality to be validated is better known.


As a customer, you have every right to request results (documents that support their execution) of at least the following operations carried out in this phase, whether in waterfall projects or in SCRUM: test plan, test case design, test cycle execution, integral test validation, and automated testing.


4. Technical debt

Technical debt is the accumulation of design or coding shortcuts that can cause problems in the future. The classic problem is that technical debt is often ignored or not managed properly, leading to an increase in maintenance costs, a reduction in performance, and limited scalability. To mitigate this problem, it is essential to identify technical debt early, prioritize it, and allocate resources to pay it off.


5. Requirements management

Requirements are the foundation of software development, and managing them is crucial for project success. The classic problem is that requirements are often poorly defined, incomplete, or constantly changing, resulting in unexpected scope, missed deadlines, and additional costs. To mitigate this problem, it is essential to involve stakeholders early in the process, establish clear communication channels, and use collaborative tools such as user stories, prototypes, and mockups.


6. Not involving the end user or client

Their participation is essential for developers to receive constant feedback that allows for adjustments during the project's execution. This avoids reaching the end, only to recognize that much of it needs to be rebuilt. The client determines the success of the software, as if the user does not approve it or considers that it does not solve the identified need or desire, then the project has been in vain.


Another fundamental aspect is not only involving the user to ensure that the software fulfills its purpose but that it does so in the best possible way, considering the interaction that the user will have with the system to provide the best possible experience.


7. Not communicating "what will happen"

A common situation is to omit "telling what will happen" during project execution. This undermines the client's expectations and can generate feelings of frustration that can be avoided. It is useful from the beginning to face what commonly happens throughout the life cycle of your project, communicating it clearly:

  • All projects can suffer delays, some due to supplier reasons, and others due to the client. That does not mean that it will not be successful in the end.

  • It may be tedious for you to be repeatedly asked about the details of the requirements, but this is important to eliminate ambiguities ("the devil is in the details").

  • You may have to participate in many meetings, even after telling your supplier everything they need to know.

  • And it will bother you that in those meetings, new requirements arise, and you are told that they are not within the original scope, demanding additional costs and time.

But if the above is not communicated and accepted in advance, unnecessary friction will surely be generated due to unaligned expectations.


At Suris Code, we help our clients avoid these situations and obtain a pleasant and stress-free project experience.

13 views0 comments
bottom of page