How Web Projects Start and End

    Good day to all!
    After the success of our previous publication, we thought for a long time who to ask to write the next article - who will be the ones who will have to argue for popularity with an article about sex. The choice fell on the technical director of 404Group Roman Druzyagin, who will talk about the launch of the project from the point of view of "technical".
    “About the“ start-ups ”, their beginning, development and ending weren’t written only by a completely lazy person, this topic is so relevant and popular. Projects appear and disappear dozens every day, which visually allows you to see services like Kickstarter. Paying tribute to fashion, I want to share some experience and a look at the start-up market, formed as a result of many years of activity in launching and growing Internet projects within our company. Many of these projects had a sad outcome, moreover, often at the very start.

    The material presented in this essay does not claim to be called the truth, but it well reflects the real situation in the average “start-up” and the typical problems that arise in it. Since I am a representative of the technical profession, then my opinion will be precisely from the position of “technicals”. What is usually done right and wrong, and what results for the project can this lead to later?

    Instead of lyrical digression

    The 404 Group company and the people who establish it have been engaged in investing in Web projects for over a dozen years. In 70% of cases, the idea is invented internally by representatives of the “ruling elite” and launched into development. The remaining 30 percent falls on promising products that we invite to cooperate with us in the organization. It doesn’t matter which of the two ways the project is within the walls of the company, then the game is played on equal terms.
    The project has a team (“techies” and “managers”) led by one or two managers who are fully responsible for the goals set for the project. In exchange, the company offers the team all its resources: financial investments in the sizes agreed by key participants, office amenities with cookies and consoles, operational support (financiers, lawyers, secretaries, HR and other specialists), technical competencies (experienced engineers, DBA, system administrators ) and other capacities that the company has for the implementation of the project.
    The development path the project will take and whether it will be successful depends on its team. Over the years of practice, it was possible to identify several typical scenarios in which a particular product develops. With experience, we have learned, as far as possible, to adjust the course of the project if we see that it has entered the “slippery track”. And some do not even take under the wing of the company as knowingly losing “black holes” in which money and other resources will only flow.

    Three typical start-up development scenarios

    Scenario No. 1 , the most promising: the project focuses on the result, adheres to the philosophy of “ship fast & often” or, in the more familiar language, “x ** k and production”. Adherents of this approach seek to bring a working product to the market as quickly as possible, to actively develop and improve it, based on feedback from consumers. The project rarely uses specific methodologies or development methods. Developers with an acceptable level of competence are hired, and work on the “features” takes place on the principle of the sudden setting of “immediate” tasks, which are desirable to do by yesterday. Such a model is as viable as possible, since it most likely provides the opportunity for the founders to demonstrate real growth and development carried out with their money. The key problem of this scenario is insufficient attention to the quality of the product, which can lead to serious risks that threaten the project as a whole.

    Scenario number 2: The project focuses on quality. Such projects are done by programmers who are bored of being a hired performer and want to try to do something different. A noble undertaking, but very often tired of the constant struggle with “bugs” and routine, a specialist makes a decision that is extremely dangerous for the project, to take everything into account and foresee it in advance. A lot of time is devoted to the correct architecture, and not enough to the development of a commercial component, namely, how the project will bring money.
    In Web projects, it’s almost impossible to consider everything. In an effort to solve this problem, the team does not notice the complete waste of investor money, and the project ingloriously dies. Many years of experience suggest that a creatively-minded manager is able to come up with a task that is so perpendicular to the current state of architecture that it will take weeks, or even months, to redo it. It is clear that in practice it is necessary to resort to less pleasant methods and sacrifice quality for the sake of speed.

    Scenario number 3: the project is not clear on what. Such projects are often stillborn at the start. The people who invented it have an incomprehensible mess in their heads of technological and commercial ideas, which does not line up in anything concrete. Amazing strategic plans are being built, a large “feature list” is being drawn. As you develop, this list is freely adjusted, supplemented and expanded. If the pace of development still manages to catch up and overtake the pace of generating new ideas before the team runs out of money, then the collected “sharing” turns out to be completely unsuitable: the functional elements are not coordinated and weakly combined with each other into a single user experience; "Usability" - at zero; with all the visible wealth of opportunities, the user does not understand at all what to do with himself, and how all this will benefit him.

    A couple of examples from practice, so as not to be unfounded.
    • Example No. 1: a large advertising network
      It was an honest and good attempt to make a successful product, which at the same time would be technologically high-quality and free from the problems that existed in other projects of the company that had achieved commercial success. At the start, several highly qualified engineers were hired, bought a lot of servers, came up with the architecture, "sawed" for more than six months and were preparing for the start.

      In practice, we got serious over-engineering, which obliged the team to support a complex multi-tier architecture on almost every task. This became especially critical at the moment when we realized that the pace of the decision in such conditions was unacceptable, and we were banally unable to keep up with competitors. In them, in the system assembled “on the knee”, the integration of a partner takes half a day, with us it takes half a week, at best. The race was lost, the project was closed.
    • Example No. 2: a small but proud social network
      At the start: the desire to do something big and bright. Due to their specificity, monetization methods are not specifically indicated. Hired by the most courageous and courageous samurai, a global “feature list” has been compiled. In practice: confusion and vacillation, the “fichelist” is growing, the architecture of the project exists exclusively in the architect’s head, any questions are answered that “everything is very complicated”, months go by, barely working registration is spinning from real indicators.
      After six months of such work, the staff was dispersed, normal engineers from the experts of the parent company were brought in, the system was designed in 2-3 weeks and assembled in a few months using the frozen “phichelist”. Whether these “features” are necessary or not, no one is already thinking, it is important to collect and show, the founders are extremely unhappy. The output is a product that is not consistent and is full of functions that are loosely coupled, which is disastrous for a social network. Another 3 months is spent on re-designing the UI, modification and editing. The project is released, it works, but the “exhaust” is zero due to a poorly developed commercial strategy. Result: the project is frozen.

    What is the recipe for a successful project? It is not difficult to guess that the product developing according to the first scenario has the highest probability of becoming successful. Nevertheless, in order not to find a commercially successful, but technologically insolvent project, it is necessary to accept some compromises that both technical department employees and representatives of commerce are ready to observe.
    • Compromise No. 1: selection and operation of technologies
      First of all, it does not matter which technologies (programming languages, DBMS, application server, Web server, etc.) and the methodology you use. You need to choose cost-effective solutions. Something popular and traditional (PHP, MySQL / PostgreSQL) provides an opportunity to hire from a wide pool of candidates at affordable prices. Of course, you can write your application in Erlang, but then you are tormented by looking for an adequate specialist who does not ask for extraordinary money.
      Secondly, it is very important to exploit the selected technologies and methodologies systematically. Do not be too lazy to establish rules and guidelines for writing and structuring code, writing comments. Introduce code review practice and make your programmers systematically meet these requirements. The success of the project lies not in the correct architecture (which at any moment will become incorrect), but in the systematic nature of its support by the team. When all programmers write code in a unified style, the cost of understanding a programmer in the essence of a task written by another developer is greatly reduced, which generally increases the efficiency of the technical department at times. Do not neglect the rules and regulations, they are almost the most important aspect of the development process.
      And never, never listen to the programmers' excuses that they cannot write accurate code at a fast pace. This is an absurd statement and a sign of laziness or incompetence. The stylistic design and coding culture is a trained skill, which is present at the level of muscle memory among good programmers. Train your programmers and let them relax.
    • Compromise number 2: the rejection of universality
      The next inalienable compromise is a conscious refusal to make a universal architecture. As one of my colleagues said, it was never possible to find the moment when the next project goes from the state of "immediately do everything right" to the state of "initially everything was done wrong." This is inevitable, and you will come across this. Accept the fact that your project will have suboptimal decisions and crutches.
      Think of how paradoxical this sounds, the rules for implementing such decisions, and document them. As a rule, these are the solutions that implement the most critical logic for business. The presence of such documentation is many times more valuable than beautiful comments in the code that are automatically converted by some tool into a beautiful HTML page with documentation on class methods. Nobody ever reads them. And, since it is almost impossible to maintain 100% documentation in an intensively developing project, immediately direct the efforts of your programmers and demand to describe the problems that really require it.
    • Compromise No. 3: Concern for Security
      Practice shows that even the most experienced programmers often have very superficial ideas about the security of a Web product. What are the typical vectors for attacks and how can an attacker exploit them? How to protect yourself from them? How to work with the database in order to avoid the loss or theft of information? The developer may not know the answers to these questions or may not pay due attention to them, since for the programmer the most key aspect of the work being done is his code.
      In fact, the most important resource of any Internet project is data. The technical department does not think about them, because the code is the core of the system, and the representatives of commerce do not think, because they have limited technical competencies and they have a headache for other reasons. Understanding and awareness of the importance of data appears at a time when the resource is attacked by competitors, as in that sad joke about administrators who do not “backup” yet and already do it.
      Make sure that there is at least one person in your team (it is highly desirable, occupying the position of a technical leader) who will convey this to the whole team, develop the necessary practices for writing safe code, monitor their system support, and establish the correct backup procedure and data recovery verification. I have repeatedly observed successful projects that “cracked” using extremely trivial vulnerabilities. A purposeful audit of completely different products revealed the same problems: lack of filtering of input parameters, unprotected forms for uploading images, etc. These are all banal nonsense that can be prevented only by consciously only paying attention to the issue of security.
      Remember, data is more important than code! You can write new code, but lost data is so easy to collect.

    To summarize

    Why is there no example of a technically successful, working project in this article? Such in nature are extremely rare. If the product really works and makes money, it will always have problems: a large number of urgent tasks, a lack of working hands to solve them, crookedly programmed modules and a strong desire of programmers to rewrite everything from scratch, daily bugs that have been waiting for their turn for months, and denial of service , crises of a commercial nature, requiring quick, quick file-cutting in half a day. All this the team will have to rake every day, and at the same time somehow manage to develop the product.

    Also popular now: