Everybody who works in the web development industry has heard this question many times: “Why is it taking so long? It’s only a small feature.” Some may say this sounds a bit offensive, but it seems like the client might assume your team isn’t competent enough or (God forbid) whether you are honest. Nevertheless, such a misunderstanding often occurs when clients are not familiar with the development process or when it’s not transparent enough. Before rushing to any conclusions, let’s take a step back and consider how it works in reality.
First, we must underline that no changes (no matter how simple they are) should be made directly in the production environment. It’s risky and against the core principles of proper development. Next, before any changes are made, we must find the specific file/section within the code where these changes need to be applied. In some cases, the change can be quick but also other changes can be more challenging. Finally, each task must be tested in a development environment before it’s pushed to production. This step will guarantee that both the new feature and the existing functionality work properly together.
With these circumstances, these procedures must be followed by all team members for all projects.
Basic Stages:
- The developer receives a task and creates a new GIT branch and works within their local environment.
- When each task is complete, the developer pushes all changes into GIT and sends the task to the Team Lead for review.
- The Team Lead will check the code to approve or send back for amendments.
- When the code is approved, the changes are merged to the development environment, where it’s tested by a QA specialist. It’s important to note that some changes apply to relatively sensitive functions (e.g. checkout), so the task must be checked thoroughly to ensure that it fits with the main functions and its working properly.
- If the task is approved and passes the QA stage, its pushed into production, where it’s tested one more time in order to ensure that all changes have been applied and works as it should.
As a result, this task takes more time than the coding itself.
That’s not all
You should also keep in mind that this is just one aspect of the development process, and other factors can take up time as well.
Additional considerations:
- Depending on project specifics, local deployment can take between one hour to 5+ hours. This due to project infrastructure that needs to be recreated and the elimination of any pitfalls.
- An internal instance for testing must be configured
- Pre-production must be set up, if necessary
When you take into account these considerations, even more stages are added to the development process.
Additional Stages:
- Task review and estimate (Coding -> Review -> Test 1 -> Test 2 -> Deployment -> Test 3)
- Acquiring access to the database, along with the code of the site/repository integrator*
- Creation of an instance: staging and pre-production (optional)
- Code review and quality control
- Testing (Test 1), with the testing being recorded for reiteration in pre-production (Test 2) and production (Test 3)
- Creation of a manual (if necessary)
- Internal and external management
As you may notice, there’s a whole interconnected ecosystem that must be taken into account. It allows us to offer customers accurate cost estimates and provide a range of options.
* A separate word about integrators
The SOFTLOFT team specializes in cloud-based services. Our integration within a project takes place with a “unified” account (for example, a CTO account) has complete access to all of the customer’s services: the server, database, code, etc. Through the help of the integrator account, the code is duplicated to an internal repository where that account is used to send updates to the customer’s repository. In addition, the integrator creates a copy of the project to the server for internal use. As a result, the customer only gives access to a single account instead of the whole team, which is highly advantageous for security and control.
Final thoughts
Is it possible to skip these additional steps to save time? The answer is “Not always”. As a possible workaround, a single task can be split into multiple tasks and distributed more efficiently. This way, each task will not demand following dozens of steps and most such tasks will be completed much faster.
We’re responsible for the quality of our code and the results of our work. We do everything possible to minimize unexpected issues that may arise in the future and we make our code clean and functional. We prefer these established practices in order to satisfy our customers’ expectations.
