In previous posts, we tackled the idea of how Making Sense approaches the development of software products. Today, Mariano Ravinale, Software Architect, explains the importance of considering technical aspects before the development phase begins. This presents an important challenge in terms of determining the best approach since it will help to reduce development costs and improve the quality of the resulting software products.

In short, technical assessment is crucial to understanding the overall focus of each stage.

The Discovery Phase

Inspired by the concept of the “inception phase”, introduced in the book The Agile Samurai by Jonathan Rasmusson, we at Making Sense named this initial phase of the development process “Discovery”. The main goal of this phase, quoting Rasmusson, is getting everyone on board, viewing the big picture, and lastly, making it real.

At MS, we’ve taken Rasmusson’s theories to heart. The result? We’ve been able to position ourselves for a better view of our projects and project stakeholders. Also helped us achieve a sense of common purpose in effectively addressing the challenges of each project.

Assessing suitable technology for implementation

One decision facing every development team is which type of application to use for creating the software product. The decision is crucial since it’s what triggers the development’s mechanisms, testing and deployment, and leads the process during project development.

For example, a mobile application has very different ecosystems and processes in relation to a desktop application or web app; therefore it is important to define, early on, the type of application that best fits the requirements of the job, in order to reach the goal of the project.
Besides, in each stack there are as many implementation possibilities as there are programming languages. Toolkits and/or frameworks are some examples of this.

Early risk communication during the Implementation Phase

We might find ourselves in the situation where a project or MVP (Minimum Valuable Product) already has a proposed direction from the technical point of view. In that case we’ll have to review the new requirements and evaluate whether it’s convenient to stay with the former technical proposal or develop a new implementation for the project.

Very often we think that adding functionalities over an already created product saves time. But most of the times, building over a weak foundation may take much more implementation time, and difficulty to estimate causing high levels of uncertainty. That’s why the expertise of a tech lead is key, since he/she will evaluate the risks and point the team in the right direction.

Technological Limitations According to Context

There are several factors that should be considered in order to identify the project boundaries. These limitations will also help in the analysis from the technical point of view. The project goals will help us in identifying the scope of work to be done and getting an estimate of the total length of the project.

But we should also consider whether there are technological limitations on the client’s existing frameworks, stack or development environments. Then, we need to assess whether those environments fit the scope of the project. If not, we’ll have to find more appropriate frameworks.

An example of this could be if the company works with technologies like VB6 and needs to implement a REST API to support a mobile application. This brings up another important factor to evaluate: do they have knowledge and technical capacity to perform the entrusted tasks?

Referring to the above example: perhaps there are many languages ​​and ways of implementing an API, and it would be OK to implement the latest framework of Ruby ​​or Node.js. But if the human capital that we have for development and/post implementation or support are people trained in VB6, perhaps it is best to migrate to ASP.NET.

Conclusion

In this post we’ve covered different key elements of our Discovery process from the point of view of the technical implementation. This involves our tech leads, and requires that they keep in mind many different considerations, including detecting future risks, finding the right technology or thinking about the future support of the product.

This is not an easy task, and many times it’s experience as much as technical knowledge that helps in making these complex decisions. I’m proud to say the team of tech leads at Making Sense has vast experience in the product development field, and that makes the process simple and reliable for our partners.