Organization of web application development

Hi! I want to share my experience in setting up the web app development company process. Together we will go from hiring employees to software testing.

Summary

Let's say you wake up one morning as a startup leader after your first round of investment, drink some coffee, and get to work immediately. Your checklist includes:

Search for employees.

Interview.

Selecting technologies for the project.

Organization of teams.

Planning. Documentation. Architecture.

Statement of the problem. Development. Testing. Control.

Administrative matters.

Tools.

Literature.

Finding employees in IT is a pain. The candidate market is already small, and now a large bank has opened a development office in our city and is vacuuming up personnel.

From the obvious

Services of specialized platforms: hh, linked. If the budget allows - expand the geography and mention assistance in moving for candidates from another city.

From the non-standard

Search among speakers and audiences at conferences.

Browse contributions to open source projects on similar or related projects on GitHub, BitBucket, GitLab.

Don't forget about active users of resources like stackoverflow in the relevant technology sections.

Use word of mouth (colleagues of already hired employees).

Organize competitions with prize funds and offers of further employment.

Search on freelance exchanges.

Organize open conferences at the company office.

Organize open days on an interesting topic, even if “interesting” is just a nice office with free cookies.

Interview

During interviews, it is important to look menacingly at the candidate and puff out your cheeks diligently. And also to overwhelm them with the most difficult tasks on knowledge of algorithms. After all, this is what the largest IT companies do!

Seriously speaking, candidates should leave satisfied, even if they are rejected. Well, at least we will strive for that.

A short, abstract conversation before the technical part helps. A smile and the magic phrase “I don’t like going to interviews myself, I was in your place not so long ago” will relax the candidate and give them more chances to open up. It’s better to ask technical questions in increasing order of difficulty, recording a conditional assessment for each section. This helps a lot when there are a lot of candidates.

The composition of technical questions directly depends on who we are looking for - a promising specialist with a good base, for whom we can spend about six months on training, or a narrow specialist with experience in this or that technology.

In addition to technical skills, teamwork skills are important. A couple of questions about former colleagues, starting with “how” or “what”, will shed light on the candidate’s conflict proneness. Don’t be lazy to look at the future employee’s profile on social networks. And don’t be shy about asking the opinion of the candidate’s former colleagues and management via a direct call or letter. But it’s important to remember that there are also dishonest people on the other side.

It is a good practice to introduce the candidate to the team and their work before signing an employment contract.

If the work is remote, clarify the availability of: a quiet place, stable Internet and self-organization skills.

Selecting technologies for the project

From my observations, the IT community is greedy for hype technologies, but we will not do so, so first of all we look at:

The specifics of the project.

Knowledge and experience of current employees.

The ability to develop a tool or technology.

An example for the last point.

Take a raw but promising technology for a startup, polish it up and get profit in the long term. And on the contrary - take a terry library for a banking project, which is very stable.

Organizing teams

We've decided on the technologies, hired people. We're forming the organizational structure.

My favorite option is atomic teams of 6-12 people . So that the team has the necessary roles: managers, testers, developers, etc. At the same time, some roles can work in several projects at the same time. For example, designers and testers.

The manager has no more than 7 employees in his direct subordination.

It is important to maintain and correct a document with the pros and cons of employees.

It's good when teams are staffed not only by technical skills, but also taking into account the last two columns. For example, add a mentor to the team to help newcomers get started. Or an innovator to bring in new technologies and tools.

It is more important for team leaders to be able to understand the intricacies of human relationships than the intricacies of code. According to the precepts of systems engineering, ideally two leadership positions are needed - a technical leader and an administrator.

Planning. Documentation. Architecture

Bureaucracy is evil, but you can’t live without it.

Planning

The project has a plan that needs to be regularly reviewed and adjusted. Even if it's in the form of notes with a pencil stub in a notebook.

first kernel version - 12.04

reports - 02.06

integrations - 25.07

beta version - 14.09

project delivery - 01.11

Documentation

We think of documentation as an investment in the future. We document: the project plan, the convention on code style, customer requirements, changes in requirements, software and hardware architecture. Documentation should be brief and as clear as possible. If the document is not clear, it will not be used, but will only interfere. We record important agreements in writing. We include a description of installation and compilation in the repository Readme.

Architecture

The architecture is formed before writing the code. Preferably in text and graphic form. When designing, we will use design patterns, take into account the expected number of users and look for ready-made solutions. For example - architectural patterns .

Let's start a glossary. This will facilitate communication both within the team and during negotiations with the customer. At the very least, there will be no confusion in the names of variables.

Statement of the task. Development. Testing. Control.

The tasks are there. The people are there. It's time to set up the work process.

Let's analyze each stage of the work process and select a development methodology.

The first is the choice of software development methodology . Don't be shy about adapting it to the project. After all, there are no projects that are ideally suited to one or another methodology.

The second is choosing a branching option in Git. The most popular ones are listed here . For ourselves, we will choose Github Flow.

Setting goals

We use task managers to set tasks. They provide transparency in development, improve quality, and minimize redundant communication between participants.

Minimum set of fields for each task:

Project.

Term.

Responsible.

Task priority.

Description.

To balance the workload of performers and control deadlines, it is important to keep deadlines and task priorities up to date.

We will distribute tasks taking into account the strengths and weaknesses of employees. We will try to move people from project to project and from task to task as rarely as possible. On the other hand, we will not let people stagnate and get bored with monotonous tasks.

My favorite good old reminder for this section:

The received task is analyzed before the start of work. Naturally, this imposes the mandatory presence of the required competence in the employee.

The received task is completed 100%. That is, any task must have a clear completion criterion. Accordingly, until it is completed, the task is considered unfinished.

Obstacles to the complete completion of the task must be immediately reported to the manager and all interested parties. That is, do not scroll cats, expecting that the manager himself will guess that you have a problem with the completion and magically solve it.

A proposal to solve a problem is preferable to information about its occurrence. It is assumed (often) that the performer is an expert, understands what went wrong and how this trouble can be quickly resolved.

An extended interpretation of the received task is not allowed. It is not necessary, they say, to guess for the manager what he meant. It is better to clarify.

Disagreement with the parameters of the task or the execution regulations cannot serve as a reason for ignoring them.

Facts and arguments are preferable to opinions. Phrases like "I don't think it will fly. So don't do it" are not what you want to hear in response to a task. If you think it won't fly, justify it by supporting it with facts.

Development

Let's take as an example a conditional task from an imaginary project “№545 Add hotkeys support for a search”.

The name of the git branch will correspond to the meaning of the task, for example: “LCC-545-search-hotkeys”.

Before each commit, we check the changes in the edited files to minimize errors.

Add the task number and title to the commit message to navigate through the change history. Example: “LCC-545 Add hotkeys support for search”.

Before sending the task for testing, we will check the task description with the result.

Let's create a pull request to improve the quality of the code and share experiences.

We will forward the task to the testing stage after the pull request is approved.

Testing

Testing is like a preventative visit to the dentist every six months - everyone understands the importance, but few do it.

You shouldn't immediately strive for 100% code coverage with tests; it's better to select and write tests for key and "bottleneck" areas in the application. This way, we get protection from regressions with a small amount of additional code.

Let's divide testing into manual and automated tests: unit tests, integration tests, E2E tests, load testing.

Unit tests

Suitable for isolated parts of code, especially pure functions whose output depends only on input data. Let's make it a rule to use not only correct output data, but also deliberately false ones. For bulky function results, we will use "snapshots".

Integration tests

We test the interaction of modules. This is a quick way to check for regressions in a large amount of code. The downsides are that you can't see where exactly the problem occurred and there are increased requirements for input and output data.

E2E tests

End-to-end tests are a great way to test end-to-end functionality in web development. For example: authorization functionality, ordering goods, building a report. E2E does not require knowledge of project technologies, it is enough to have a knowledge of the testing framework.

Load tests

A good way to catch functionality that has become very “heavy” in a release. A must-have if your project already has: significant traffic or heavy calculations.

Manual testing

Manual verification of the result of the completed task and the overall functionality of the project helps where there are no automated tests or where they do not work: the layout has gone wrong, there are problems with accessibility, the functionality is inconvenient, etc.

The approach does not require development skills, thereby saving the resources of expensive developers.

Control

Let's start with the logic of the problem.

The director checks that the result corresponds to the task description and does not require revision. If the task is set incorrectly or not fully completed, it is returned to the development stage, with appropriate comments.

Code review (PR).

Here the quality of the code improves and developers exchange experiences.

Let's sketch out a rough checklist:

Can it be simplified?

Is the code at the correct level of abstraction?

Is the code divided into modules?

Does a solution come to mind that is better in terms of: maintainability, readability, performance, and security?

Is there similar functionality in the codebase?

Are there “best practices,” design patterns, or language-specific patterns that could significantly improve this code?

And by the way, use linters to check style, indents, etc.

At this stage, we briefly write down the results of each employee's work in a table. And then we summarize the results at the end of the week, month, quarter, year, in order to objectively evaluate the person's work for the selected period.

CI/CD

Cool stuff. Reduces release time. Improves: scalability, fault tolerance, documentation.

We select and configure one of the platforms for automatic assembly, testing and code loading.

We will make one environment for development, where branches from pull requests will be deployed automatically. An example address is “lcc-821 -add-another-pyment-system.pr.lcc-project.com“.

Another environment will be similar to the production version, for final testing of releases.

The third environment is the production version.

Administrative matters

In addition to the development process, you need to remember:

Other important roles in the company

Training and exchange of experience among developers

The atmosphere in the company

Motivations

Other important roles

Our project involves collecting and analyzing a large volume of requirements, followed by analysis and documentation.

That's why we have a vital need for technical writers and analysts.

With the first ones, everything is simple - they greatly simplify the maintenance of internal and external documentation.

It's a bit more complicated with analysts. They know both the subject area and the product. They collect requirements or analyze problems, turning them into a verbal description of what needs to be done in the product.

And everything that analysts have come up with and developers have written needs to be thoroughly tested. That's why testers are simply irreplaceable. They know the product from the user's side better than anyone else and save a lot of time for other roles.

Training and exchange of experience

As the professional growth of employees increases, the quality of the project also increases.

Therefore, we will allocate time for:

Cross code review.

Pair programming.

Internal meetups. Make sense when teams work in isolation.

Organization of spaces for team interaction. For example, a channel in a corporate messenger for technical issues.

Atmosphere in the company

Let's take note: conflict management, burnout, feedback.

Toxic employees are those who interfere with the normal work of their colleagues. We ask such people to leave if we cannot protect the team from their influence.

Burnout is a prolonged feeling of exhaustion, decreased productivity. Solutions: a long vacation, a change of activity or project. Otherwise, the company risks losing the employee.

Feedback from a manager is a powerful incentive for employee web app development company . We adhere to a simple rule: reward publicly and scold privately. We back up information with facts and try to be as unbiased as possible.

Motivation

The team must love what it does, and everyone must feel like a part of it.

To do this, we will convey user feedback to employees. Involve the team in solving common issues.

The employee must be confident that he will be encouraged for successes and reprimanded for failures.

Incentives can be material: bonus, payment for courses, conferences.

And non-material ones: a promotion, the opportunity to implement new technology, public praise.

Examples of blame: lack of bonus, switching to boring tasks, team pressure (realization that you have let the team down).

Tools

The choice of tools directly affects the success and effectiveness of the project.

General

Use tools to enforce static typing if the language you are using is dynamically typed.

Don't skimp on hardware and software.

Connect linters for automatic code quality control.

IDE

Products of JetBrains, VS Code.

Task managers

Asana, Trello, Click-up, Jira.

CI/CD

TeamCity, CircleCI, Travis CI, GitLab.

Testing

Cypress for E2E. Jmeter for load testing.

Documentation

Confluence, Google Doc, Wiki.

Literature

I recommend:

“The Mythical Man-Month” - Frederick Brooks.

“Rapid Development” - Steve McConnell.

“Deadline” - Tom DeMarco.

“Done. Project Management in Practice.” - Scott Berkun.

Conclusions

Employees are our everything. Use non-standard sources to find candidates. Choose interview questions in accordance with future tasks. After the interview, candidates should have a positive impression of the company.

When choosing technologies, consider: the specifics of the project, the knowledge and experience of current employees, the ability to develop a tool or technology.

Divide employees into atomic units. Keep track of team members' skills. Pay close attention to social skills when choosing team leaders.

Write documentation. At a minimum, the overall architecture and business logic. Maintain a project plan. Record agreements in writing. Use architectural patterns when designing. Write briefly and clearly.

Choose a software development methodology and define web application development services stages. Use task managers. Write tests to find regressions and control scalability.