The staff of the web studio "Glyanec.NET" has always followed the principles set out in the article. We recommend to get acquainted​​​ — https://habrahabr.ru/post/151902.

There is no red pill

What is it about?

I have long been an adherent of the ideas of equality, freedom and brotherhood that there is a red pill.

— That it is possible to solve all problems of scaling of programs by means of "OOП";

— That with the help of one methodology it is possible to build project development;

— That with the help of several ingenious books you can learn to design interfaces.

In fact, after a couple of dozen projects, I've come to the conclusion that it's all nothing more than a delusion, and miracles only happen in the books of authors who make millions on their bestsellers. Or in the minds of consultants who make money by selling you bullshit in the form of Agile, KPI and other clever words. I may not make any discoveries in this post. But I will save you a couple of years if you decide to believe my experience.

There is no design

Perhaps, after N iterations, the developers begin to tell you - everything, you can’t do the project further, you need to refactor. Better yet, rewrite from scratch, otherwise it will fall with each new change. And if you obey them uncontrollably — they will refactor for two months, in two months they will decide to rewrite from scratch. And six months later, when nothing is ready, either they give up a useless venture, or you fire them, the market has gone ahead and you won’t be able to get on the train that has already left.

Or, if the developers already had refactoring experience in another company, they will immediately offer you to design immediately. UML, the use of sophisticated tools and so on — let's do everything right right so as not to rewrite. This may concern not only programmers - the designer will try to draw the final layout immediately, so that he can hand it over without alterations. But that does not work. 

People do not get along with one simple thought: the ideal does not exist. Any designer, programmer, specialist, looking at his work a year ago, will find many mistakes — because he grew professionally. This means that any result can always be improved. However, the same people will convince you with foam at the mouth that today they have learned Zen and will do it right away. Do not listen to them. 

Look around: nature does not design immediately, it does billions of iterations and applies positive feedback (sorry, creationists have found the transitional forms nevertheless). And develops organisms through evolution. Therefore, from my experience I made a simple conclusion — despite idealism, the first three to five iterations of the system must be done quickly (usually with hardcode and govnokodom). A kind of interactive prototypes on live data, on which developers really know the details of the subject area, and the customer finally understands what he needs. After that, you can design, but never before. Even Martin Fowler seriously discussed evolutionary design (and dead traditional).

No methodology

Here I will be brief. We tried fixed iterations, try kanban. Since I am a programmer, in addition to PM, I can confirm that all methodologies really come down to write-code-somehow. And the less unnecessary actions are introduced into the process, the better. Daily compulsory conversations are a minus (we communicate in the evening and more often on-demand). Planning poker — not needed: as a rule, in my projects there are a lot of complex dependencies, and it is impossible to model them accurately; which means that the estimates will only take time and dominate when you took them on yourself. Instead, there are simple estimates: do it right away, do it in an hour, in a day, and so on, that is, order.

A separate point is the rejection of the fixed iteration. I don’t know how others do, but in my projects, as well as in startups, frequent releases and quick changes are very important. A bi-weekly fixed release is IMHO nonsense, and we abandoned fixed iterations in favor of kanban, which is why. However, we are not alone — here are 50 months of the evolution of development, the guys came to the same conclusion.

I also want to note the twitching. We have a regulation (with its implementation it’s not easy, but we don’t give up) about the hours of silence: at least 4 hours a day, the programmer should work without any IM tools, because nothing infuriates how to switch questions.

In general, so far I have not seen a universal methodology. When I was in high school and had a project management course, we got married to RUP. Then he studied Agile. In practice, the former is simply dead for IT, a rapidly changing market and industry. And the second is an open secret. Everyone says that they really know all the secrets and can deliver development. But more and more often govnoproekty enter the market, and everything is done very slowly. But consultation offices are booming. Amazing right? Instead of doing the projects themselves, they make grandmas on coaching.

In addition to units, like some who have been driving development for 5-10 years in Google or IBM, basically these guys IMHO should not even come close to consultations, unless there are really cool projects in the portfolio.

What is there?

There are only people. According to the doctor of biological sciences Sergey Savelyev, who he outlined in the book “Variability and genius”, people's brains differ significantly (individual structures up to 40 times). Roughly speaking, everyone has a unique brain. And the whole task is only to select for you the most ingenious, imprisoned for the right job. Because certain large structures in the brain will pull a person to do what he has a gift for. Therefore, the best people always have a thrill from work - but not because they chose such a job, but because they were originally created for it and just correctly guessed.

Therefore, I am looking for those who like his work - this is a sign of giftedness (at times of genius), and that a person has chosen his path correctly (and not by force, for the sake of money, he studied Java or Photoshop there, and is engaged in what he is not gifted).

One great programmer is worth ten gouging or mediocre. One smart, sociable, energetic leader who infects others with energy and is able to win the respect of programmers costs ten ordinary PMs and hired consultants for rabid grandmothers.

Therefore, I am making every effort, as far as possible, to seek and retain people. I do not believe in methodology - if there is no project that believes in the project, and no team of smart people, everything else does not matter. And I do not believe in the ability to do good right away, but I believe in evolution.

Who wants to spend money, time and their efforts on red tablets in the form of Agile, or thinks that now smart programmers will design everything, and designers will draw - ok, go! You can design before the third advent, and try to build the perfect burndown chart until the fourth, while 10 hosts are raging from incorrectly selected user stories on your project.

I wish you not to waste time on garbage, but rather focus on finding and retaining the best of the best!

Epilogue

The post is dedicated to the very units, those programmers, project managers and designers, and all specialists who work hard and do real work, and not IBD, like many of their colleagues. People like you are the IT elite and the driving force behind the world. Isaac Asimov spoke well of you in his story Profession.

[...], and the one who does not want to come to terms with this is the person we are looking for. This may be a cruel method, but it justifies itself. You can’t tell a person: “You can create. So come on, do it. ” It is much more accurate to wait until he himself says: "I can create, and I will create whether you want it or not." There are about ten thousand people like you, George, and the technical progress of one and a half thousand worlds depends on them. We cannot afford to lose at least one of them or spend efforts on someone who does not fully meet the necessary requirements.