Interview with Mariusz Wróbel, Team Leader at Edge One Solutions
Several years ago, when the pace of the development of artificial
intelligence and machine learning mechanisms increased
significantly, it began to be said that the programming profession
may not have a future – applications were to write themselves.
Why did these predictions not come true?
In the application development process, human is irreplaceable, and I doubt that this will change in our lifetime. The programmers’ duties consist not only of writing code, but also of developing their array of additional skills and knowledge, among which the most important is learning about the business aspects of a particular company, how work is organized, how the various departments within the company communicate, and so on. Currently, one of the most popular application architectures is microservices – a project is divided into small parts, and a group of programmers is responsible for creating each part, but all these parts must form a coherent whole. That’s why people must talk to each other, determine the scope of work, and verify the results – I can’t imagine machines being responsible for all this.
Nevertheless, code generators have already been created …
Yes, but only in those areas where a lot of things are repetitive so that the work of programmers became reproductive rather than creative. Page generators are the best example. You still need a human being to decide how you want a page to look, but the generator already takes care of “translating” his vision into page description language. If these are largely passive sites, and user interaction is limited at most to the implementation of a comment module or a simple online store, then there is no problem. This one, on the other hand, comes up when it is necessary to implement complex business logic and make the application behave in a very specific way.
Could an alternative here be no-code platforms, the creators of which boast about the possibilities of adaptation to the needs of virtually every recipient?
These types of platforms, contrary to promises, have many limitations. Their architecture is tailored only to specific needs. Once the applications created with such tools reach a large scale of operation, they begin to lack performance. I can use an example: for Allegro, our company created a system for handling the Smart program. This type of function, as well as most loyalty programs, cannot be handled with an off-the-shelf platform. All this must be programmed, considering individual needs related to business or logistical aspects, as well as hundreds of nuances that the creators of no-code platforms simply did not foresee. Sometimes it happens that it is necessary to create something that no one else has done before. During several years of my programming career, I had several situations when it was necessary to come up with something that had never been on the market before. Sometimes it was necessary to create completely new features, to modify existing ones, such as those available in the open-source model.
What is currently the biggest challenge in running software projects?
A wise and very diverse team that has comprehensive knowledge, but at the same time can cooperate and is communicative during conversations with business departments. It’s just like in sports – if we gather a group of stars, they will constantly argue because everyone will want to score goals. And we need a team that is in tune with each other, forms a whole, and plays toward one goal. When the team includes only senior developers who already have established habits, it will be difficult for them to get along, and the code development will take longer because they will not be able to find a compromise. It is equally important that the business side has realistic requirements and respects the opinion of programmers, with particular emphasis on the estimated time of implementation of a given project.
What types of problems may occur in this area?
Let me give a hypothetical example of an unrealistic business expectation. In October, the company reports the need to implement a discount code system on its online store platform to make it available before Christmas. To do this it is necessary to modify the payment operator’s API – it takes a month. We, on the other hand, need another two months for the entire procedure to carry out appropriate tests, and analyses, implement mechanisms for monitoring the correct operation of a given system and collect opinions from users. This means that we will be ready, but only for February.
What should be done then?
In such a situation, it is necessary to work out a compromise and give up something, accept some risk, or plan activities in such a way that priorities are implemented before a holiday, while additional things are implemented next. Risk analysis at this stage is crucial. It can, for example, provide information that a certain problem will potentially affect only a small percentage of users and it will take less time to help them manually, such as through customer service than to create the perfect solution. As a result, it is more profitable from a business point of view. It is equally important to build the client’s awareness of the difficult situation he puts us in.
Are there such difficult challenges on the technical level as well?
OWhen it comes to programming, almost everything is doable, it’s just a matter of time. However, a very big challenge is to model the project, i.e., transfer the business vision to code and implement it in an already functioning large system. It is important to be aware that it will include logistics, payments, and integration with other operators…
To integrate everything effectively, it is necessary to consult with external suppliers, discuss how to implement them on their side, agree on all contracts, etc. Then the project should be divided into smaller parts and executed.
One may get the impression that in this type of project, technical aspects do not play a major role, either on the business side or on the programming side, but the so-called soft skills and ability for working in a team are key…
That’s right. Of course, technical skills are important, and it is necessary to have them at a certain level. But if the software we create concerns mainly the business layer and not some narrow specialization, e.g., writing complex algorithms or creating drivers for new equipment, our tasks are technically relatively simple and are based on combining individual elements, or supplementing them with necessary functions. We develop mechanisms that need to count, analyze, and display content in a certain way to cooperate with the systems of other suppliers, etc. We can do it because we’ve been doing it for years. What’s more, we use frameworks in which many of such mechanisms, such as sorting or comparing objects, for example, have already been implemented, so you just need to use them skillfully. Therefore, the most important thing is to skillfully transfer the organizational structure of the project to the structure of the application. Thanks to this, you can divide the system into small parts, assign code maintenance to individual teams and ensure their effective cooperation.
If you are looking for a team of developers with years of experience, contact us!
