How a web programming company should work

The history of this article began at least seven years ago when, after working in a German web company, I passed under the wing of a large final customer and started working remotely.

Life has become calmer, the child has grown up, some free time has appeared and I have started a little freelancing. After some time, together with a few friends with similar experience, they decided to organize a small web development company to master, among other things, the local market, to raise large projects and in general for further development.

At first, there was a lot of organizational work and other routine work, but this can only partly serve as an excuse that I came to my senses only a few years later and finally realized that I was not working at all the way I would like and, moreover, those fundamental things that I took for granted, for my comrades, perhaps they are not at all.
')
And then, in the end, these self-evident, obvious things decided for me to formulate a “manifesto” (he-he), a concept, description and list of what the company shouldn’t use without, IMHO. I’ll clarify that this is not about working with a client, not about management as such, not about money and business plans, but about organizing the work of a small firm of web developers (and, perhaps, not just web), about what you need do what is important to do in order to work successfully and develop.

I will try to abstract from the technologies and software used to give a bit of generality to the presentation, but it is important that the specificity of web development in a small company is discussed: this is a large number of relatively small projects, dependence on other technologies and services, as well as many different approaches to solving the same problem and even choosing technologies for the project.

Let's start with the definitions.
A small group (5-6 people) of developers are united in a company (firm) in order to work:

• receive income from the activities of this company
• enjoy this work and results.

Based on what we already know and want to do, our company should deal with:

• first of all, programming projects of different complexity for the web (starting from large software systems and right up to business sites of several pages),
• to maintain their own hosting service for their needs and the needs of their customers,
• offer system administration services for remote servers (primarily for hosting), services and databases,
• do web design
• engage in support, SEO and consulting in the field of web-technologies.

In other words, to provide the client with a full cycle of work, starting from planning and ending with website promotion. The order on this list is of course very important. Here we focus on development / programming, we declare that we will be engaged in system administration, but only within the hosting, as a rule, of our own projects and are not going to compete with anyone else here. We also need design for our projects, but we do not position ourselves as a web studio, design is not a priority for us to develop. And support and SEO are completely secondary and important only in the context of a full service cycle.

From the human resource, for the beginning, we need only a few developers / programmers capable of learning, to grow into a team with a view to its subsequent expansion and transformation in the future into several similar teams (divisions). Must be present competent system administrator. We also need a designer and "SEO", perhaps at first and not on a permanent basis. And, perhaps most importantly, an interested leader is needed. Director, project manager, analyst, organizer, and much more in one person.

It is also important to determine the basic values. In order to ensure the stable development of the company in the future, we want to provide professional growth opportunities for each employee and to maximally stimulate and simplify the process of sharing knowledge and information between developers. The atmosphere of openness and desire to learn and - especially - to share knowledge should be strongly encouraged (among other things, such an atmosphere in itself serves as an excellent motivational factor). However, the direction of the whole process in a reasonable direction is also mandatory, and here we cannot do without some restrictions. And the most important thing that we want to achieve as a result of such restrictions is the interchangeability of developers as much as possible, of course.

As a digression, a few words about the material (about workstations). Ideally, unless of course we are developing products for Microsoft products, do not use proprietary software here. Experience shows that today open source solutions are quite enough for us and it seems quite logical to keep only one machine in the office under MS Windows (for the designer, visual testing). It makes no sense, however, to limit developers to, for example, only one Linux distribution, here everyone has the right to organize his own workplace as he likes (with the exception of common tools - see below). It makes sense, however, to conduct all (or almost all) development on the internal development server (see also below) and for this purpose do not skimp on good hardware and the network.

Ok, let's say that we have an understanding of all this and we have distributed the roles.
How should the team work?

In my opinion, the following things / practices / approaches in our work are required.
So, Important:

1. Use a single coding style (notation and general principles). Make the rules a small document.
2. General IDE and a common set of other tools (for example, programs for working with databases). An instant messenger, of course, everyone can use which one they like, but working on the same technology one cannot keep an IDE zoo even if it is not worth the money.
3. Using version control system for ALL projects. It makes sense at least to view the code (at least for the search for “where have I already done this?”), For deployment, for rollbacks and rework at the request of the client, even if only one person works on the project. IMHO, the preferred organization for our company is still not distributed, but centralized repository organization.
4. Maintain all projects through a single project management system (PMS): basic planning, task tracking, request and bug tracking, time tracking, partly CRM. It is desirable, of course, to write your own for your own needs, but you can put it ready, it is not desirable, however, from my point of view, to use third-party services. It is impossible to allow situations when, for example, files from a customer or correspondence lie where they were decided to be saved by the project manager (as a rule, in a folder on his desktop) - there is a strictly defined order for all documents.
5. Mandatory use (creation, replenishment, updating) of a resource with documentation, books, help files, etc. - general knowledge base. Delivering code fragments and step-by-step instructions to a structured wiki resource common to the company.
6. It is very, very desirable to test the code. Unit testing for particularly critical parts of the project, and ideally TDD as the norm of life.
7. Use a single style of documenting code for one specific documentation generation system. Documentation, however, is provided and maintained only for projects where it is specified separately.
8. The team should have a good knowledge of one or two frameworks and use only them to develop relatively complex projects.
9. Use one or two CMS for relatively simple and simple projects, it is desirable to study them to all team members.
10. At the same time, it is worth working with a relatively large number of DBMSs.
11. Constantly work on self-education, training new employees, interns. Primarily through the holding of general weekly seminars. It is also advisable to regularly analyze code fragments, sometimes practice pair programming.
12. Plan the development of new technologies and work methodologies. To carry out a planned transition to new software versions.
13. To strive to carry out competent planning of work on projects, to give preference to iterative planning with a short cycle. It is imperative to assess the real costs, the speed of the development teams, etc., to do the analysis and conclusions after each project is closed, it is very desirable to reflect this in the PMS.
14. In addition to planning and maintaining tasks, it is imperative to write a short technical specification for each project and keep it up to date.
15. Maintain a permanent recruitment and screening of candidates for work, the planned work on their training.
16. Have plans for short-term and global company development. Regularly adjust them.
17. Have an appropriate marketing strategy.
18. The development should be carried out on a separate server for development, the only scheme of support and allocation of resources (sites in operation) on this server is important. Three-level layout of the project in the development process: development, preview, production. Development and preview can be physically kept on the same office server. All dev-server resources without exception must require authorization or be accessible only from the local network and only in read-only mode.
19. We need a single concept / scheme for providing access levels to resources: who, what, from where and even when. For example, it should be mandatory to restrict access to the repository, at least for new employees, either on an individual project or its parts or only from the office, but open to everyone and everyone in the company access to a common knowledge base / wiki resource (for authorization). In other words, while encouraging openness, sharing information and experience within the company, we should also think about preventing information leakage. In this regard, it is also important to convey to each developer the notion of whose property the code written for the company becomes (but do not overdo it!).
20. We need a single backup scheme for the office and the dev server (backup for production is a separate task). In the simplest case, when development is carried out exclusively on the server, the workstations can not be backed up at all and leave this question for consideration of who is working on it.
21. Uniform policy to work with proprietary software on workstations. On the installation of each vareznoy program (why and on what term) the director's notice should be considered mandatory. Strive to use only licensed copies of software (yes, buy, if necessary).
22. What is important is a clear separation of management and project development functions. The programmer actually never has to directly contact the client, all tasks must go through the project manager. Strive to ensure that developers do not work simultaneously on several projects (as far as possible, of course).

Each item appeared on this list for a reason and can be reasonably explained in some detail: why it is so and not otherwise. Nevertheless, everything stated above, in the end, is still the result of personal experience, therefore it does not pretend to be complete or - even more so - the ultimate truth.

Here, if possible, short and everything.