Be wary of generalizations
There are many fashionable modern concepts: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. They are all good. Understanding, and even more use, greatly expands the horizons. But we must understand that these are all pretty common things. We must not forget to use the head and clearly realize the applicability in your own project.
Fanatical following of methodology reminds delight from understanding of some possibility in a programming language. I myself succumbed to this more than once: “Cool, there are metaclasses in Python — we use it urgently in the project” —even the same could be achieved with the usual class attributes. “Wow, Lisp macros are super, we will need more of them” - although it was possible to do with higher-order functions. First, you do this, and eventually you get used to it and you don’t get into this powerful opportunity anywhere, and only use it if you really need it.
All theories were once young. Even those that are now considered unfashionable and outdated were once a breakthrough. Just now they have lost their former brilliance, just as powerful features in a programming language are losing their brilliance.
')
Where is the moment when they become obsolete? Where are the conditions in which they work, and in which they no longer exist? Maybe the new trend has already become a stable stereotype and further movement is necessary? These questions should always be asked to yourself and use / not use the concept, not because it is progressive / outdated, but because it is suitable / not suitable for you personally in a particular case.
I will give a few examples.
In the examples, there is specifically so much negativity, not because I want to provoke a discussion, but because you will not find it in the corresponding books / blogs / lectures. It is clear what sense to agitate for their theory, showing its shortcomings. Because of this, it turns out that new concepts that no one has yet denied look better than they really are (what they will look like in 10 years).
On the other hand, if you fall into criticism, there is a danger of making a mistake by simply saying “Methodology X is not for me.” The problem may be a lack of understanding, or inability to apply. It is necessary in such cases to try, try on a new idea for yourself, try to really use it, and not to fence off. Maybe use some part, not immediately. In general, to link with reality and then draw conclusions. But not the general conclusions "method X - shit, method Y taxis", but specific: "method X did not work, because there were such and such circumstances, but method Y rescued because it fit the situation."
Once again: I do not criticize new trends. I just want to call for common sense those who say "we use Y and therefore we will win." Techniques are not invented by the gods, pulling them out of the universe continuum, but by people from experience, analysis and the use of different approaches. No need to consider yourself obviously below the authors and blindly repeat them. You need to expand your vision with the help of their ideas and follow your own path.
Fanatical following of methodology reminds delight from understanding of some possibility in a programming language. I myself succumbed to this more than once: “Cool, there are metaclasses in Python — we use it urgently in the project” —even the same could be achieved with the usual class attributes. “Wow, Lisp macros are super, we will need more of them” - although it was possible to do with higher-order functions. First, you do this, and eventually you get used to it and you don’t get into this powerful opportunity anywhere, and only use it if you really need it.
All theories were once young. Even those that are now considered unfashionable and outdated were once a breakthrough. Just now they have lost their former brilliance, just as powerful features in a programming language are losing their brilliance.
')
Where is the moment when they become obsolete? Where are the conditions in which they work, and in which they no longer exist? Maybe the new trend has already become a stable stereotype and further movement is necessary? These questions should always be asked to yourself and use / not use the concept, not because it is progressive / outdated, but because it is suitable / not suitable for you personally in a particular case.
I will give a few examples.
- If you are building a complex product that allows you to optimize logistics, then the simplified version may not be of any interest to anyone, because “all this can be done in Excel”. This does not mean that the idea is bad and needs to be changed. This means that it still needs to be brought to a more or less digestible state.
- Apple has never been a model of "frugality" and always counted only on their own considerations. And did a good job. Maybe that's why it is not bad that he did not give the design of devices into the hands of customers who, in fact, do not understand this?
- Suppose you created a page and described what you are going to do (this is already considered a MVP). You have 10,000 subscriptions. Hooray, you can work! But it’s not a fact that you were understood exactly as you think. And not the fact that it will be possible to realize everything exactly as intended. In the end, 10,000 users, seeing the result, turn away from you, saying that you promised another. And there will be no second chance to create a first impression.
- It happens and vice versa. You created the description (MVP) and everyone tells you, “why do we need another one [product category]”. Although victory can lurk in the details - in those for which competitors are simply incapable and difficult to imagine. The author of DropBox was able to make a convincing video and interest thousands of people, having convinced that it is not “just another backup system” but something more convenient. But Google at one time would hardly be able to interest someone with a drawn window for entering a search string. We needed real results to be different from other search engines.
- Are daily / weekly rallies on your team good? Do they not remind of ordinary meetings at which, in essence, there is nothing to say and everyone is just waiting for it to be possible to go to work?
- You are just starting to design and every day adjust the interfaces in your prototype. Is it not strange, together with the code, to rewrite tests, knowing that they will become obsolete by tomorrow? Maybe you should wait until the architecture settles down a bit?
- You try to keep the product minimalistic, without adding complex features to it. Users are satisfied with ease of use, developers are satisfied with ease of support. But check to see if you are missing 90% of the market, without giving it something important. Many are switching from BaseCamp to Megaplan just because of the lack of necessary things (however, 37 signals do not notice outflows and are proud of their position to this day).
- "We are creating a web service for working with vector graphics." Are you sure that the user will be comfortable using the Internet to work with heavy files needed on his computer, and not on your server? Will he really try to make drawings from a tablet or even more from a mobile *? Are you sure that the support of powerful servers for processing graphics will not force you to increase the price of your product 10 times?
* hint - quite often to the draftsmen, and the 20-inch screen is not enough
In the examples, there is specifically so much negativity, not because I want to provoke a discussion, but because you will not find it in the corresponding books / blogs / lectures. It is clear what sense to agitate for their theory, showing its shortcomings. Because of this, it turns out that new concepts that no one has yet denied look better than they really are (what they will look like in 10 years).
On the other hand, if you fall into criticism, there is a danger of making a mistake by simply saying “Methodology X is not for me.” The problem may be a lack of understanding, or inability to apply. It is necessary in such cases to try, try on a new idea for yourself, try to really use it, and not to fence off. Maybe use some part, not immediately. In general, to link with reality and then draw conclusions. But not the general conclusions "method X - shit, method Y taxis", but specific: "method X did not work, because there were such and such circumstances, but method Y rescued because it fit the situation."
Once again: I do not criticize new trends. I just want to call for common sense those who say "we use Y and therefore we will win." Techniques are not invented by the gods, pulling them out of the universe continuum, but by people from experience, analysis and the use of different approaches. No need to consider yourself obviously below the authors and blindly repeat them. You need to expand your vision with the help of their ideas and follow your own path.
Source: https://habr.com/ru/post/186778/
All Articles