Choose your dev team: 12 pieces of advice from a PM

If you are hiring or building a team of software developers to implement your product idea, you must be already familiar with numerous pitfalls that are out there. I do not promise to reveal a silver bullet, but I am going to describe the essential items I pay attention to and the common misconceptions I have seen. This information is most likely valuable for business owners and their representatives who decided to hire software developers. The pieces of advice apply to outsource companies, freelancers, and in-house staff.

1) You do not want a single-discipline specialist

What differs software development from other industries is that each project is unique and each time it is necessary to solve the problem from scratch.
For example, to open a bank account, the employee must perform a number of actions that is the same for each client: scan the passport, select the account type, sign the contract, issue the card. However, no one has a plan and a list of steps to implement your unique idea. Together with the team, you try different ideas and different ways to implement them. Of course, I am not talking about typical tasks or the configuration of a specific solution for you.
For example, to create a typical website in a CMS such as Wordpress or Joomla, you should look for candidates who specialize in this topic. However, to develop a custom solution you do not need a programmer who’s familiar with your domain or with the UI solution you want to implement or with the services you want to integrate. Besides, having experience with some specific technology, e.g., with a particular API is not a guarantee of success, because everything in IT is changing very quickly and the experience gained six months ago may be irrelevant today. Instead, you need to make sure that the developer knows how to work with the documentation, knows how to google and do research. You want the programmer to have problem-solving skills and not the knowledge of an exact algorithm or tool.
It is more or less typical for developers to change jobs every few years to learn something new for themselves, which means that the background of each will all be different and diverse. Also, vice versa, if a programmer is engaged in solving one typical problem all their life, it is more likely because of their unwillingness to learn and evolve.

2) No need to have same online hours

You may want all the team to be online during your business hours. The team’s presence may create a feeling that everything is under control and you can chat at any time, e.g., to ask the status or discuss something. However, in fact, the main work is done just outside of chats and meetings. Few hours of overlap per day is enough for communication and coordination, having more is not a must.
If there is underperformance, then usually changing the online hours does not solve the problem. If the project does not move without daily communication with the team throughout all the working day, then something is very wrong with the process.

3) “Cheap” is expensive

The market offers a vast range of hourly rates and salary expectations; I would like to give an example:

- The programmer A ($N/hour) creates you a page which submits the form; the work takes 4 hours. QA needs 1 hour to test it, during which he/she finds a minor bug, the programmer fixes it during half an hour, QA retests for 15 minutes more. The work is ready. 5 hours 45 minutes in total.
- The programmer B ($M/hour, where M is twice smaller than N) creates you a page which sends the form; the work takes 6 hours. QA needs 1 hour to test it, during which he/she finds 10 critical bugs and 5 bugs of medium severity. Programmer B needs another 4 hours to fix 10 critical bugs, QA retests again (1 hour), finds 5 more critical bugs. The programmer needs another 4 hours to fix, QA retests again, this time it is half an hour. Because the deadlines are tight, the bugs of medium severity are left without being fixed. 16 hours 30 minutes in total.

From what I have seen so far, in almost all cases, a more experienced(and more expensive) specialist completes the task faster and better than less experienced(and less expensive). So in absolute numbers, often the “expensive” is “cheaper” because they deliver faster.

In addition to retesting and bug fixing, consider the additional time required for management, which in the second case is more. I do not rule out the possibility that a more expensive programmer for $N/hour can underperform, that is another problem, but please remember about the “hidden” price — rounds of bugfixes, retesting, additional communication and shifted deadlines. Also, the poorly written code is harder (means longer and thus more expensive) to maintain in the future, in the worst case it is just impossible.

I would like to note that of course for solving simple problems it is not mandatory to have much experience. Moreover, it is still possible to search and find a great expert for a rate below the market value, but be ready to invest much effort into the hiring process. Also, there is a risk that the employee leaves once they have a better offer.

4) Take hiring process seriously

Please, please, please spend enough time to describe the job position, screen candidates and interview them. Introducing each new person into the project is costly, everyone has to go through the onboarding and learn the product, and the consequences of poor work can be expensive — problems with security, data loss, or eventual re-writing of all the code by other teammates. So the very process of firing is stressful for everyone. Therefore, select carefully, arrange several interviews and make a decision in a balanced manner.

To give you an idea — under the current market conditions it is okay to spend up to 3 months and conduct around 20 interviews to hire a developer.

5) Git knowledge is a must

If you have more than one person in the project, you must have git or another version control system. It is the only widely used method at the moment which allows several people to work on the same code base. The ability to work with git is critical, without it two or more people are not able to work simultaneously on the same file or module. So your project can be full of the files like function1.js, function_old.js, function.new.js.
Just remember how it was to work on the same document with different people before Google Docs appeared.

6) So is continuous integration (CI)

For the new code to start working on your site (or, more correctly, on your server), you need to put this code on the server and make it available for the process which executes the code. There can be a lot of updated files. This process has been automated long ago with the help of CI — the robots take the updated files, put them where necessary and make the process execute them. You can do it many times a day; this process is painless.

In most cases, when developers insist that git and CI are too complicated and unnecessary, it indicates a lack of experience and a reluctance to learn.

7) Having tests in code is a long-term profit

Some programmers tell you it is expensive, complicated and does not make sense to write and maintain tests. Consider this as a red flag. (It is fair to add that if someone insists that your project must have 100% of test coverage, it is also not okay.)

An example. Your new feature is to add information about a new employee to the system. When adding, a new page appears and after adding a message about the successful addition is shown.
The test checks that the new page opens, checks that you can not submit invalid data, checks that valid data is correctly added to the DB and the correspondent message shows.
Seems to be an unnecessary work? If the project consists of one feature that will not change — yes. QA tests this case manually. However, once you start adding new fields to the employee profile and trigger employee adding from other places of the system, the test immediately shows to the developer whether anything is broken. Seeing the problem even before testing saves the time dramatically: the developer sees the error right away, which eliminates unnecessary bug report, fixing and re-testing. Yes, there should be a balance between how long it takes to write tests and how much time they save, but to develop a complicated system without tests is quite risky.

8) A ‘senior supervising juniors’ model does not work

Another scheme that I did not see efficiently working, but which everyone tries to build is to have a team of one experienced developer and give him/her to lead the juniors. Of course, if the ratio of simple vs. complex tasks is 1: 2, then one experienced and two juniors is a perfect team structure. Still, usually this is not the case, and the tasks are more or less balanced, which requires a balanced distribution of skills in the team. Is it possible for the senior to spoon-feed the solution to the juniors? It is, but it takes as much time as to deliver them on his/her own. Also, a programmer is usually motivated by solving problems, unless this is a designated person at the position of human development manager. Plus, everyone is interested in working with colleagues who have much to learn from. Therefore, in the scenario of babysitting the juniors, your main developer is likely to be quickly demotivated. Of course, I do not encourage not to work with juniors at all. You need to remember that they need to be given the appropriate tasks. If a person is assigned something that goes far beyond their competence, they are also uncomfortable and do not work productively.

9) No, they are not hired guns

If you are planning more or less long-term cooperation, do not treat your employees like hired guns. If you consider them as a tool to “do this exact thing that I ask without sidestepping,” then you get the same result. They show no initiative or proactivity, they do not feel responsible, they do not correct accidentally found bugs — they were not asked for it! They will not seek optimal solutions.
On the contrary, let them feel that they are making a product with you, that their contribution is essential and the opinion is valued. This will bring you shared ownership, which leads to shared responsibility and increased productivity.

10) Code review can be quite subjective

Be careful when asking someone to do a code review or audit of someone else’s project. Often such an analysis involves much subjective opinion. Yes, there are best practices, but a lot cannot be unambiguously classified as black or white. If a reviewer is someone whom you plan to potentially take over development — watch out, they are financially interested in having a project, so the results may be biased. Also, there are too many perfectionists among developers, and for the successful operation of the product, the code does not have to be perfect.

11) Refactoring is not evil

You will hear the word “refactoring” a lot. It does not mean “give us money, but we won’t deliver anything in return.” Refactoring is a healthy part of the process. The codebase evolves, changes and sometimes some parts of it need to be rewritten, or refactored, so that code can be properly maintained. E.g., in the new modules, you use new libraries and a new API, and you need to make one small change in the old module. And for this change, you need to refactor the old module so that it also starts using a new library and API, because this small change needs to obtain data from the new library and API.
However, it is worth remembering that refactoring can take an infinite amount of time if it is not limited in any way. Remembering about the perfectionism of developers and abstract nature of the work, we can expect that the developer at some point starts refactoring for the sake of refactoring, and not for the sake of that small change. Therefore, always have a timeframe for refactoring and a clear understanding of what is being refactored and why.

12) They will not make you the right product

Remember (and this is very important) that the technical team deals only with technical issues. Do not expect them to be marketing assistants or to guarantee that your idea is viable and stands the competition. Or that they create an intuitive interface and that users will love the product just for being well programmed. No, it is all outside of the development scope. Yes, someone can have some specific background and advice on some issues, but this is not a common practice. Developers solve only the problem of how to program your idea right, and this is already quite a challenge itself.

The relations are always bilateral, and you would benefit if the team treats you with loyalty and respect. If the relations are far from great and you are not the only client of theirs, then there is a big chance your tasks are not of the priority and that you are not given the best resources (if it is an outsourcing company) and that your problems are treated with indifference.