The answer is quite simple: the one that the client finds suitable.
The problem with any choice is that all people are different. The estimation criteria for any applicant, service, or product are different as well.
For somebody, knowledge of French literature of the Middle Ages may be crucial because the developer should name all classes, methods, and properties after literary characters of that period.
However, if you do not have the same approach to selecting, and still need to choose one developer out of millions, you can look for advice that classifies the choice criteria.
I would like to mention that all criteria described below do not represent the absolute truth, but are a call to reflection rather than to blind actions.
So, what would you expect from the development process? For me, the central attributes are reliability, quality, development speed, and trustworthiness. Let’s examine each component separately.
I understand reliability to be whether or not you can count on your developer.
Can you say for sure that your developer will accomplish the work within the given time and budget limits?
Can you say for sure that he will not disappear, forget anything, or take your rival’s side?
Can you say for sure that, once the system is done, you can ask the same developer to adjust the system with no extra charge for learning time, just as it happens when you replace the developer?
All these issues are critical for any system that is more complex than a “Hello World!” program.
The quality of the work done must correspond to the system requirements. When a developer designs a scooter that would withstand the melting temperature of steel, this is impressive. However, scooters are made to be used by ordinary people and such supercritical operating conditions are simply not necessary. This means that when a developer would design a system based on these kinds of reasons, he would make the client greatly overpay for unreasonably overestimated features. On the other hand, when a newly built house cannot withstand a breeze or a little rain, it is impossible to use such a house because it does not conform to functional requirements.
Apart from ‘external’ quality, there is also a demand for ‘internal’ quality. In fact, you can easily distinguish a Russian car from a German one even when you see a photo of the location of the nodes and units under the hood. How rationally and elaborately the elements are deployed, as well as how hard it is to maintain and service the system are issues which indicate ‘internal’ quality.
It takes time to develop an application. They do not emerge immediately just as ideas. Unfortunately, such is reality.
Even development teams, companies, and international corporations have activities that cannot be accelerated. Imagine if one book is written by several authors. How many writers can participate in the creation of a quality product?
Let’s assume that the final version contains 500 pages. Talking further in mathematical terms, let’s assume that it takes a day to write one page and five seconds for a single word. Thus, if we contract 500 people and give them the task of writing a page, we will get 500 pages per day. And if a page has 400 words, if you can get 200,000 people to work, you could churn out 500 pages full of words in just five seconds! Isn’t this accelerated development? No, it isn’t.
As a result of the first alternative, when 500 authors cooperate, we would get a product that would need long lasting improvements. As a result of the second experiment, we would get a meaningless 500 pages of hodgepodge.
What should you do? Coordinate creativity.
In fact, the writing speed of a group of authors would depend on the writing method: they either build the general storyline, and after that delegate details to every author, or the stories connect with each other only slightly, or authors review each other to achieve elegancy. Even with something like writing, there are different possibilities for cooperation, so acceleration depends on the writing style, the type of literary work, and the needs of the target audience. The main point is that the speed of work should be satisfactory for the client. However, clients should be aware that when a developer tells you impossible time limits, they are probably a swindler; you can write 500 pages in 5 seconds but it will in no way resemble a book.
It is implied that any work is mutually profitable. The client is happy to spend his money and time to achieve his desired result. The developer is happy to spend his energy to earn money and master his skills. But when this relationship contains discrepancies between the parties, the situation turns woeful. No contracts, oaths, signatures or seals can solve the problem. At best, you would waste your time, nerves, energy and money to prove your right at court, and as a result, you would be compensated for your losses. Will you receive a solution for your plans? If your aim is to win some money, then the answer is probably yes. For all remaining cases, do not work with people whom you do not trust.
Quite often you hear that a development company can be replaced by individuals. So, why pay big enterprises when there are lots of talented entrepreneurs with passion and charisma?
Eventually, the Internet makes it possible to communicate directly with any person on the planet. “Liberty, equality, fraternity”. But let’s check how both individuals and companies match with the points mentioned above.
Well, who is more reliable: a single developer or a company? outsoursing or nearshoring? It is a fairly big risk to depend on one person. Even though the individual is enormously loyal, honest, open, unselfish, and loves his job, the human remains a biological entity, and it is in his nature to get tired, sick, or even die. Certainly, unscrupulous companies can also simply sell their workers’ time and do not care about spreading knowledge about the system which is being developed, motivating employees, or planning replacements for the workers who quit the job. However, individual developers lack this option at all.
When one person designs a system from scratch, he will know it inside out. However, we cannot know how well it is designed. A perfectionist will think it is magnificent according to his own standards. An interesting question is whether his opinion will coincide with the opinion of the person who works with the system. The lack of several opinions during the planning stage, when gathering requirements, or on the testing stage, may be both an advantage and a serious issue. Certainly, it may be said that a developer cannot independently and critically examine the quality of his own work.
The fact that companies must work more productively than individual developers emerges again and again. This is only part of the truth. If there are processes that can be completed simultaneously, companies will be able to work a lot faster. Naturally, this concept works on big projects. However, for small or highly complex projects, adding new workers does not necessarily mean accelerated development.
Trustworthy relations are a subtle matter. A person can love a brand for many years but try a muffin in a tiny bakery around the corner and change his mind within a moment. A company with impeccable service becomes so impressive in clients’ eyes that the company itself takes on its own personality and becomes like a trusted individual. Wise in-house organizational processes increase clients’ confidence so that they trust the company like an old friend, or even more.
And still, how can I find my best developer?
Go through a list of recommendations, talk to people whom you trust, and try to make a short list of candidates based on your own criteria (read more how to find a programmer for a startup). At the next step, you give the candidates a simple task to see how the development process is organized and whether it meets your requirements. This way, in a few iterations, you will move closer to the starting point in your truly trustworthy relationship with the developer who deserves to be working with you.
We hope you will make a clever choice!