📜 ⬆️ ⬇️

Red pill does not exist

What is it about


For a long time I was an adept of ideas about equality, freedom, and brotherhood that there is a red pill.

- What is possible with the help of OOP to solve all the problems of scaling programs;
- That with the help of one methodology it is possible to build the development of projects;
- That with the help of several genius books you can learn how to design interfaces.

In fact, after a couple of dozens of projects, I came to the conclusion that all this is nothing more than delusions, and miracles occur only in the books of authors who make millions on their bestsellers. Or in the heads of consultants who make money by selling you bullshit in the form of Agile, KPI and other clever words.
')
I will not make, perhaps, in this post any discoveries. But I’ll save you a couple of years if you decide to believe my experience.



No projection


Perhaps, after N iterations, the developers begin to tell you - everything, then the project can not be done, it is necessary to refactor. And even better - rewrite from scratch, otherwise it will fall with each new change. And if you listen to them uncontrollably , two months will refactor, in two months they will decide to rewrite from scratch. But in half a year, when nothing is ready yet, either they abandon a useless venture, or you dismiss them - the market has gone ahead, and getting on the train that has already left will not work.

Or, if the developers have already had experience refactoring in another company, they will immediately suggest that you design it right away. UML, the use of complex tools, and so on - let's do everything right right away so as not to rewrite. This may concern not only programmers - the designer will try to draw the final layout immediately, in order to pass it without alterations.

But it does not work. One simple thought does not get along with people in their heads: the ideal does not exist. Any designer, programmer, specialist, looking at his work a year ago, will find a lot of mistakes - for he grew up professionally. So, you can always improve any result. However, the same people will convince you with foaming at the mouth that today they have known Zen and will do it right away.

Do not listen to them. Look around: nature does not design immediately, it makes billions of iterations and applies positive feedback (sorry, creationists, transitional forms have been found after all). And it develops organisms through evolution.

Therefore, I made a simple conclusion from my experience - in spite of idealism, the first three to five iterations of the system must be made quickly (as a rule, by hardcode and govnokod). Peculiar interactive prototypes on live data, in which developers really get to know the details of the domain, and the customer finally understands what he needs. After that, you can design, but in advance - never.

Even Martin Fowler seriously argued about evolutionary design (and about the traditional dead)

No methodology


Here I will be brief. We tried fixed iterations, tried kanban. Since I am a programmer, in addition to PM - I can confirm that all methodologies really boil down to write-code-blyat.rf .

And the less unnecessary actions are brought into the process - the better. Daily mandatory conversations are a minus (we communicate in the evening and more often on-demand). Planing poker is nafig: as a rule, in my projects there are a lot of complex dependencies, and it is impossible to accurately model them; so, the assessments will only take time and finish when you take them on yourself. Instead, simple estimations: do it right away, do it in an hour, per day, and so on, that is, order.

A separate item is the rejection of a fixed iteration . I do not know, like the others, but in my projects, as well as in startups, frequent releases and rapid changes are very important. Fixed release every two weeks - this is IMHO nonsense, and we abandoned the fixed iterations in favor of kanban for this reason. However, we are not alone - these are 50 months of the evolution of development , the guys have come to the same conclusion.

I would also like to note the dergotny. We have rules (it’s not easy with its implementation, but we don’t give up) about hours of silence: a programmer should work at least 4 hours a day without any IM tools , because nothing is as annoying as switching questions.

In general, while I have not seen a universal methodology. When I was in high school and was a project management course, we were wooed by RUP. Then he studied Agile. In practice, the first is simply for IT, a rapidly changing market and industry, just dead. And the second is an open secret. Everyone says that they really know all the secrets and can put the development. But increasingly, govnoproekty enter the market, and everything is done very slowly. But consulting offices are flourishing. Amazing right? Instead of doing the projects themselves, they do grandmas on coaching work.

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

And what is there?


In general, Stalin is not with them, and only mass executions will save the country , as one undemocratic leader of our country says.

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

Therefore, I am looking for those who like his activity - this is a sign of talent (sometimes genius), and that the person has chosen his path correctly (and not by force, for money, learned Java or there Photoshop, and does what he is not gifted with).

One gorgeous programmer is worth a dozen or a little gibberish. One clever, sociable, energetic leader who infects others with energy and is able to win the respect of programmers is worth ten ordinary PMs and consultants hired as mad grandmas.

Therefore, I make every effort, whenever possible, to find and retain people. I do not believe in the methodology - if there is no project that believes in the project, and a team of smart people, everything else does not matter. And I do not believe in the ability to do well 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 right now, smart programmers will design everything, and designers will draw - ok, go ahead! You can design before the third coming, and try to build the perfect burndown chart before the fourth, while 10 hosts rave about the wrong user stories on your project.

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

Epilogue


The post is dedicated to the very units, those programmers, project managers and designers, and all professionals who work conscientiously and do real work , and not IDB, like many of their colleagues. People like you are the IT elite and the driving force of 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. It may be a cruel method, but it justifies itself. You can't tell a person: “You can create. So go ahead, create. ” It is much more correct to wait until he himself says: “I can create, and I will create, whether you like 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.

Source: https://habr.com/ru/post/151902/


All Articles