Why adding a new feature isn’t just two lines of code

As an enterprise-grade software engineering company, Academy Smart has to answer a fair share of quite repetitive questions: why did you select this or that programming language? Why do you plan to field 5 specialists and not 3? Why not field 10 to cut the development time in half then? Discussing this usually takes a ton of time and effort, so this article is aimed to explain our approach to the software delivery process.

Any changes can be easily handled: myths and facts

There are many misconceptions regarding software delivery, mostly based on a previous bad experience. At Academy Smart, we delve deeply into project preparation exactly for the purpose of ensuring seamless, transparent, and predictable product delivery. Below, we bust some more software development misconceptions.

More than five minutes of work: what do developers really spend time on?

If a developer says they need 7 hours to code a feature, do not expect it to be ready in 7 hours. The new feature should be tested, documented, integrated with the rest of the codebase, and unit tests for this code must also be written, etc. Some time must be allocated to discussing the progress with colleagues during daily meetings, some time must be reserved for emergencies that can happen. Requesting exact estimates for every task is counterproductive micromanagement that will drain both your and the developer’s resources.

How developers estimate the timing of building programs

For example, there was a real story of an Oracle database developer, which showed the horror of adding even a single small feature into an enterprise-grade platform.

Such complicated cases are rare (thank God!), but our developers do work according to SDLC requirements, be it an enterprise-grade product, or a simple app:

1. Requirement gathering and analysis
2. Preliminary feature design
3. Writing automated user tests and configuring CI/CD DevOps tools
4. Writing the code itself and running tests locally
5. Merging the code into a new product version for QA in testing environments
6. Deployment of new product version
7. Ongoing maintenance

By following SDLC best practices, we are able to provide realistic (yet not exact) estimates of the time needed to deliver every feature. Be aware, that one of these best practices includes having up to 30% time in reserve. This ensures that responsible developers can deliver polished products instead of half-baked code.

Factors affecting the real scope of work and its duration

Keep in mind, that there are several not-so-obvious challenges that impact the code delivery process. It is not enough to simply write the code, as we have to ensure it works and does not break anything. This means some time must go to meetings and discussions, code refactoring, and testing before pushing a new batch of code into the CI/CD pipeline. This is where this 30% extra time comes in very handy.

Finally, let’s talk about the factors that affect the real scope of work estimates and don’t depend on developers only.

1. Task-related uncertainty. Even if the team has accomplished similar tasks multiple times, every business runs a different technology stack and uses different processes, with tools having different dependencies. Aligning those with the technology stack used by Academy Smart might be seamless — or not.
2. Task innovation degree. If the project is first-of-a-kind, mastering the needed technology stack might need more time. This is better than doing costly mistakes.
3. The technology stack used. There is no “best” programming language or framework. Most of them offer similar capabilities and functionality, though some are better suited for particular purposes. However, the best technology stack selection for every case depends on the expertise level at hand — both for developers who will build the product and for your IT team that will run it. Most of the time, using simpler tools pays off in the long run — and sometimes you must go for a certain tool. Also, product architecture is of great importance here. If the feature was not planned from the very beginning, adding it might require significant reworks of the existing product architecture.
4. Source code quality. As mentioned above, building atop shoddy foundations is not the best approach. If something works — don’t fix it, sure. But if you want to improve and expand your product functionality, code refactoring or writing certain modules from scratch is sometimes needed.
5. Product optimization. Most of the time, adding new features causes internal conflicts with various existing modules, even despite the most in-depth planning. Resolving those conflicts and optimizing the product might be necessary, and it’s best to be prepared for this.

We are sure most software engineering companies will ensure you that they are able to deliver whatever functionality you need. Many of them can do it, yes — but there always are factors that influence the situation, and knowledge of these factors is the best way to avoid risk.

Forewarned means forearmed, after all.

Conclusions

Here at Academy Smart, we believe that partnership must be transparent to be mutually beneficial. This article gave you a glimpse of why adding a new feature does not equal adding two lines of code. Preparedness is half the success, so we prepare all projects with equal diligence, be it building a new CRM or eLearning system or simply adding several features to an existing product. You can expect the same level of attention to detail.

Should you like to discover how we can provide value for your business — get in touch!

Iryna Kurkina

CBO at Academy Smart