[Versión en castellano]

I’m going to tell you something that it is quite obvious, the main goal of software development is satisfyng business needs.

However, although this is completely true, we shouldn’t make the fatal error of equating how things should be done, with what should be done. If we consider ourselves as professionals we must take into account a set of intangibles as adaptibility and the maintenability in the future.

On the one hand, adaptibility allows a system to include, for example, not previously previewed capabilities at a reasonable cost or even provide it with mechanisms to support an increasing number of users in an organized way. On the other hand the maintenability is also related to the ease of adding changes in a developer independent way, system robustness or cost minimization. In fact, both aspects are quite related, but I think it is interesting to consider them as different visions of the same reality.

During all these years, I have made by best effort to define how Divisa iT products and projects should be developed, focusing on maximizing the compromise between technology and business needs. This idea rests on three main pillars.

Patrones-es

In the following sections I’ll try to describe how we work according to these pillars.

Patterns and best practices

Within this pillar I’m not really talking about software architecture, since I think it is quite imposible to provide with a general approach to every software project we are working on or will work in a future.

However, there are a series of common patterns which we can apply in the different products and projects we work on. These patterns are precisely intented to focus on adaptability and maintenance.

As an example in both our backend and frontend developments, we take into account the following approachs.

• Layer separation, SOLID principles, API orientation, testing, both functional and as an aid to improve software design.
• Common standard. In wich we define naming strategies or code documentation.
• Functional programming approach, as Java and JavaScript lambdas or REACT function components
• Preferring strongly typed languages, as, for example, TypeScript instead of JavaScript

Ensuring pattern adherence

My motto here could be to convince, not to impose and try to learn. I cannot deny that sometimes a "just because" is a response, but I try to minimice its usage. Since, in my opinion, convincing and receiving feedkback are the only ways both to achieve a successful result for everyone and ensure future improvement.

I usually use a group of more or less fixed questions, which depend on person experience and problem complexitiy. These questions include ones as why do you think that approach is the best?, if this situation happened which would be the result ?, how could yo verify that application works as expected with your sofware design?

Thanks to these type of questions, I believe that it’s possible to have a productive dialog. In these dialog it’s possible not only to describe our approach, but also to adquire a better understaing of the other person’s ideas. Furthermore if the new idea were better than the previous ones this dialog could lead us to an improvement in tools and processes,

Enhancement of creatitivity

I think that it’s hard to find anything sadder that having a series of working automatons. It is true, that sometimes, when the timing is short, the only solution is, perhaps, to manage the process down to the smallest detail. In any case this situation shouldn’t be desired at all. In fact, I’m totally convinced that each person can be creative in their work, and one of my goals is to make it possible.

Obviously how this could be done, depends on each person. In some cases it will be an endogenous process. As an example, I’m not a REDUX’ fan, since I don’t really like its side-effect approach for the applications we work on. But, I’ve never rejected the idea of its usage. In fact, when I’ve been asked I’ve always encouraged its use, enabling developers with the responsability to answer themselves if this solution is the proper fit for their problem.

In other cases, it will be necessary to help them just a bit, letting them know that perhaps it would be a good idea to change processes, tools or procedures. As when we transform our CI process to a git and gradle based one.

Summary

At Divisa iT we try to apply previous experience – both good and bad – to our work process; promoting the best of each person in order to get the best result and focusing on business and clients needs.

Credits

Icons courtesy of Flaticon

• Adaptation icons created by Becris - Flaticon
• Maintenance icons created by dDara - Flaticon