The biggest myths about custom software development
Myths have been a part of our life since the early days of mankind, and even in our high tech world they are still around. On behalf of Tproger, we spoke with Cinimex’ top people from the development division and asked them about the myths they have come across in custom software development, the origin of such stereotypes, and, most importantly, what it is like to work in an integrator company.
MYTH: Customers outsource the least compelling tasks
Yuriy Chvyrov, head of architecture, Cinimex
This myth appeared with the rise of insourcing – when customers started to set up their own development teams. To motivate their staff, customers may keep the most interesting tasks to themselves. On the other hand, big customers have more projects and tasks than what they can handle in-house. There are cases when companies initially look to IT integrators, and mainly recruit managers for their own teams. Some tasks are outsourced in full, and we have such turnkey projects in our portfolio.
As for compelling state-of-the-art technologies, sometimes, the customer leaves the choice to the integrator. In such case, we have a free hand and try to use the most advanced approaches, technologies, frameworks and products. One of our tasks is to evaluate the customer’s own competencies and select the solutions that they will be able to maintain and take further. In our work, we strive for a golden mean between new technologies and our customer’s competencies.
Sometimes, a customer may have their own stack, or they pick the technologies by themselves, in this case, our choice is slightly limited. However, many of our customers use state-of-the-art tech stack for software development, such as Kubernetes container orchestration system or Openshift, Apache Kafka brokers, S3 storage, and other solutions.
So there are enough interesting projects for everyone – in-house teams and integrators.
MYTH: Custom development strictly follows the brief from customer, and projects have no evolution.
Evgeniy Kovaltsov, head of follow-up and support, Cinimex
In the last decade, custom development has transformed into custom product development using specific principles and approaches, such as DevOps methodology. The benefit of custom product development is that the company doesn’t need an in-house product team, management and expertise, these tasks are undertaken by the integrator.
Custom development no longer works in its old shape, so we switched to the iterative approach to project management. Such approach builds on a vision, which draws on the market situation, rather than a particular customer brief. For example, we delivered a project, but suddenly there is a need to add new features and functions to it. These projects evolve. Can you complete a custom development project that continuously evolves?
And even if some issues were discovered in use, a member of the team can initiate automatic error recovery or suggest a solution, which can help avoid the identified problems. Every person may introduce innovations. In this sense, iterative approach promotes professional growth and a pro-active attitude.
Yury Chvyrov, head of architecture, Cinimex
There is an opinion, that custom development, unlike product development, lacks continuation, and the team doesn’t know how the product would perform in the production environment. Let’s take other scenarios, when a product’s life doesn’t end with deployment, and there is follow-up support. Sometimes, the customer sets up support in-house, but a more frequent scenario is to keep the outsourcer on the job. When we develop a solution, we offer a warranty on it. If something happens, our people will look into it. As a specialist, I’m always curious to see how our solution performs in battle, in production. It is a useful experience.
MYTH: Testers and developers are competitors
Alexander Buyko, Head of quality assurance, Cinimex
The cliché that testers and developers are competitors can primarily be spotted in the IT communities online, where you can find lots of different memes about it. Real-life situation is different.
Many people have heard of the Dunning–Kruger effect and the curve of self-confidence. The hypothesis goes that less competent people are more likely to overestimate their abilities compared with people who are actually competent. This effect also manifests itself in the IT field. Junior specialists may think they wrote a perfect code, but testers could spoil it for them. Middle-level coders may do a good job, but be convinced that it has flaws. In this case, testers confirm the lack of deficiencies, thus empowering the developer.
When I joined Cinimex as junior tester, I misguidedly thought that if I found an error, I had to point the finger at the developers, that their code wasn’t good enough. But I was quickly explained that the company follows the Agile manifesto. One of the things stated in the manifesto is that the whole team is responsible for a service or product. Developers and testers should be very specific about the bottlenecks of a product, code or software. This team spirit is especially important in big projects, involving big teams of developers, testers and analysts, and project managers promote values of the Agile manifesto. With such approach, the whole project team becomes responsible for quality, and testers and developers end up to be allies and not rivals.
Myth: Outsourcer doesn’t have a say
Yury Chvyrov, head of architecture, Cinimex
The general belief is that as the owner of tasks, it is the customer who makes decisions, while the contractor’s job is to do as they are told. My experience has been different. At some projects, the customer invites the contractor to help address global and strategic tasks and share their expert opinion. Certainly, all the decisions need to be approved with the bank. But this is no different from when an architect from the bank’s in-house team comes up with an initiative, they will need approval too.
From the conventional approach to an integrator’s job, you get the impression that all we do is implement business applications. But we are also engaged in platform services, when our people drafted rules of development for the customer. We wrote a concept and had it approved by our colleagues from the bank. This is the level of Enterprise-architecture, when our employees team up with corporate architects to develop the global strategy. Overall, working in an integrator company gives you a chance to be heard and try yourself as both architect of business applications and enterprise-architect.
Source: Tproger