When we talk about the development of a new application, the application development process usually includes five main stages: Planning, Design, Development, Testing, and Launching the live application. Each stage plays an important role in this overall process. Planning is one of the most important phases because anything that is not well planned will affect all other phases.
I think the majority will agree that the most important thing is to do the planning well and in detail so that all other phases proceed with as few problems as possible.
What happens when developers get involved from the development phase?
Let's say that we are working on the planning of a new application, and the first phase—the planning phase—has supported the development of the entire application with detailed documentation. The idea of the application itself has been transferred to "paper".
After that, in the second phase, the idea from 'paper' is transformed into a visual form, gradually giving us a clearer picture of what the future application will look like.
In the third phase, the development of the application itself begins. If developers get involved only from the third phase, it can lead to the following scenario: Planning starts with the assumption that the application can be fully developed according to the documentation, the design follows the planning, and then, in the third phase, a problem arises.
Developers realize that some parts of the application simply cannot be developed according to the given documentation. They then present their problem, time is spent looking for an alternative, adjusting the design, and updating the documentation. Any problem identified at a later stage results in additional costs.
Why should developers be involved in all phases of development?
The most common problem developers face when they are only involved from the development phase is that they are presented with a finalized design, a large amount of documentation to review, and too little time to provide a detailed and accurate estimation for the application's development. During this period, issues such as incomplete documentation, unfinished designs, or inconsistencies between the design and documentation often arise. All of this leads to increased frustration among developers and insufficient time for a thorough and precise development estimation.
As a result, deadlines are frequently missed, and additional unplanned costs are incurred. For this reason, developers should be involved in all stages of application development. By doing so, potential issues can be identified early in the planning phase, unnecessary costs can be avoided, developers will experience less frustration, and development estimates will be more accurate—ultimately reducing the risk of missed deadlines.
Outsourcing and engagement of developers in the project
The most common scenario where a developer is involved only from the third phase is outsourcing. This is where we frequently encounter all the problems mentioned above. Ideally, developers should be involved from the first phase, but in most cases, clients already have detailed project documentation. So, how should this be approached?
It depends on the type of project. If it is a fixed-price project, the developer or tech lead should be given enough time to thoroughly review the project documentation. Before committing, we should carefully consider whether to take on such a project and be fully aware of the risks involved. A fixed-price project should have a clear vision of the application, well-written project documentation, and a completed design that aligns entirely with the documentation.
If any step in the development process is unclear from the project documentation, or if the design does not align with it, this should immediately raise concerns. In such cases, we should carefully reconsider whether to proceed with the project. An estimate based on unclear documentation can lead to unforeseen development costs and, ultimately, turn potential profit into a loss.
On the other hand, for projects that are billed upon completion, it is crucial to begin development as soon as possible and complete it efficiently. However, even in these cases, it is essential to provide a well-calculated deadline for the application's development. Again, this brings us back to the importance of developers having clear documentation and a well-defined design, allowing them to provide a more accurate estimate.
Developers should not make compromises by providing estimates for projects with unclear documentation. Instead, they should alert their superiors that an estimate based on incomplete information could result in additional costs and extended development time. Alternatively, they should list all unclear areas and request additional clarifications before providing a development estimate.
To create a reliable and high-quality estimate, the person responsible must have sufficient technical knowledge, complete and clear project documentation, and a finalized design that fully adheres to the documentation. However, in most cases, this is not the reality. Given this, we must acknowledge from the outset that there is a high risk that such an application may not be developed within the stipulated timeframe and could potentially incur additional costs.
Should errors be categorized in relation to the phase of development from which they arise?
Another important aspect is errors within the application itself. When we talk about testing and bugs, testers are most often focused on whether the application complies with the project documentation and test scenarios or not. In most cases, the application is also tested by analysts/architects who participated in the planning process.
When we look at testing from the tester's perspective, if they encounter any problem—whether related to functionality or the appearance of the application—everything is reported as a developer's error. However, this is not actually correct. If something was overlooked during planning or a mistake was realized in the testing phase (e.g., the documentation does not state that a field is required), it is not considered a planning error but rather a "developer's" error. Similarly, if the design is inconsistent or does not align with the project documentation (e.g., "wrong label name"), it is not attributed to the designer but again marked as a "developer's" error.
In the end, the biggest burden and blame often fall on the developers, as they are held accountable not only for their own mistakes but also for issues resulting from poor planning and design. Naturally, this leads to increasing frustration among developers. If developers are solely responsible for bugs in the application, then they should be involved in the development process from the very first stage.
If developers are included only from the development phase, should bugs be categorized based on the phase they originated from? My answer is YES. Resolving bugs always impacts development time. However, if the original estimate was based on planning and design, then the time spent fixing bugs or making changes due to poor planning or design should be considered when determining the delivery deadline. In other words, if the estimated time for bug fixes or additional modifications differs from the original estimate, then the delivery time should be adjusted, and the new deadline should be accepted as the original one. It should be clear why the deadline was moved (if applicable) and which phase of the process the error/change belongs to.
Conclusion
In order to reduce the risk of errors in the application, avoid unnecessary costs, meet delivery deadlines, and ensure that each phase of application development proceeds as smoothly and "painlessly" as possible, it is essential to involve developers from the very beginning, in the first phase.
To provide an accurate and high-quality estimation, the person responsible must have sufficient technical knowledge, complete and clear project documentation, and a finalized design that fully aligns with the project documentation. Developers should not compromise by providing project estimates based on incomplete or unclear documentation and poor or incomplete design. Instead, they should inform their superiors that an estimate cannot be given without additional clarification or that such an estimate carries the risk of additional costs.
If developers are not involved in all phases of development, errors and changes should be categorized according to the phase from which they originate, and the original delivery timeline should be adjusted accordingly—provided the issues did not arise from the development phase.
