October 12, 2017 at 12:35Unusual mitap about Java in St. Petersburg on October 30
For those who are tired of technical meetings about libraries, tools, frameworks, we have prepared something completely different - a meeting-discussion “Java and bicycles: when is it worth investing in writing your own tools on the backend?”
We always have a choice. Develop your own frameworks, or get one ready from the supplier. Java, Spring, Hibernate, etc. If we take something out of the box, we can make a good product. If we want to create something special that makes us stand out from our competitors, the development of our own tools can be justified - we will understand exactly how it works and we can get the most out of it. So in which case it makes sense to invest in the development of internal tools, and in which you can be satisfied with ready-made solutions?
New versions of large frameworks for major languages appear, open source develops, and one way or another, questions arise, in which case does the project architect have the right to experiment with new technologies? When can these tools be deployed at the company level? How much flexibility in the choice of technology depends on the size, age of the project, internal or external customers.
There are many differences between developing your own product and custom development - your own development lives by different rules, and that is why the same solution can be bad for outsourcing, but beautiful and elegant in developing your product.
Program and speakers:
1. Dmitry Mamonov, Wrike “From bicycles to motorcycles: why developing your own solutions may be better than using ready-made frameworks.”
I will tell you how the process of developing your own product differs from outsourcing projects from a technical point of view, when it makes sense to invest in development from scratch, and when it is better to take a ready-made solution. There will be several examples of our projects, in which I will show what advantages we got by undertaking to make our own decisions, and what difficulties we encountered in the process.
2. Vladimir Krasilshchik, Yandex “Welcome, or cyclists are not admitted”
What do you think, in the modern automobile industry, under what circumstances does a car concern invest in the development of its own power window, and not take a ready-made, good and standard unit? Or when the automaker is developing a new battery, and not content with the standard? Maybe even give an example of such a company?
Or here you are, how often do you personally collect a vacuum cleaner yourself from improvised means or, say, sew a suit to order in an atelier? Or, perhaps, the “normal” use case is a trip to the store and choosing a home assistant or new products from the finished product, perhaps with some compromises regarding their initial ideas about the ideal candidate, for example, in the form of missing mother-of-pearl buttons or present wings?
But in our area of software development for some reason, writing your own bikes has been raised almost to a romantic degree. Moreover, the developers are proud of their bikes, actively share them and share them on github, demonstrating at least the presence of a ton of free time! Honestly, it seems to me that most of these “bicycles” turn out to be either “Hello World” level projects with the goal of learning something, or as in that joke: “We don’t remember why we invented a billiard ball from which hair grows, but it was hellishly complicated. ”
In my presentation, as a pragmatic developer, I discuss the questions that a “cyclist” or a “cyclist” team lead should ask before going to the Tour de France. I will give examples of libraries and frameworks, the appearance of which was, in my opinion, justified and motivated by a pragmatic approach, as well as provide examples of creations, the occurrence of which I can not explain, on the basis of pragmatic considerations.
3. Vyacheslav Lapin, EPAM - «Hacking" entry curve “”
The invention of “bicycles” is a great way to learn! Beginning artists mostly copy the paintings of masters, so why is IT NIH syndrome considered evil? Indeed, in order to understand how a library or framework works, it is best to try to solve the problem that they solve on their own by writing, as a rule, something like that.
Since then, when our industry abandoned the model “got an education - went to work using the accumulated knowledge base until retirement”, and switched to a model of constant, permanent training (in fact, training and work became one, single process), bicycle building is perfect for us This is supported, in fact, making up the essence of the practice in training - we read tutorials, articles, watch speeches at conferences and try to try some of this in our combat projects, thus finding the shortest path along the “curve ode ”to a new technology for itself.
However, often this is not the shortest, cheapest and safest way to solve the problems of the customer’s business, so a rare customer will agree to this. Where in this situation to go to the "poor developer" - this will be discussed in my report.
→ Registration
→ Live Broadcast
We always have a choice. Develop your own frameworks, or get one ready from the supplier. Java, Spring, Hibernate, etc. If we take something out of the box, we can make a good product. If we want to create something special that makes us stand out from our competitors, the development of our own tools can be justified - we will understand exactly how it works and we can get the most out of it. So in which case it makes sense to invest in the development of internal tools, and in which you can be satisfied with ready-made solutions?
New versions of large frameworks for major languages appear, open source develops, and one way or another, questions arise, in which case does the project architect have the right to experiment with new technologies? When can these tools be deployed at the company level? How much flexibility in the choice of technology depends on the size, age of the project, internal or external customers.
There are many differences between developing your own product and custom development - your own development lives by different rules, and that is why the same solution can be bad for outsourcing, but beautiful and elegant in developing your product.
Program and speakers:
1. Dmitry Mamonov, Wrike “From bicycles to motorcycles: why developing your own solutions may be better than using ready-made frameworks.”
I will tell you how the process of developing your own product differs from outsourcing projects from a technical point of view, when it makes sense to invest in development from scratch, and when it is better to take a ready-made solution. There will be several examples of our projects, in which I will show what advantages we got by undertaking to make our own decisions, and what difficulties we encountered in the process.
2. Vladimir Krasilshchik, Yandex “Welcome, or cyclists are not admitted”
What do you think, in the modern automobile industry, under what circumstances does a car concern invest in the development of its own power window, and not take a ready-made, good and standard unit? Or when the automaker is developing a new battery, and not content with the standard? Maybe even give an example of such a company?
Or here you are, how often do you personally collect a vacuum cleaner yourself from improvised means or, say, sew a suit to order in an atelier? Or, perhaps, the “normal” use case is a trip to the store and choosing a home assistant or new products from the finished product, perhaps with some compromises regarding their initial ideas about the ideal candidate, for example, in the form of missing mother-of-pearl buttons or present wings?
But in our area of software development for some reason, writing your own bikes has been raised almost to a romantic degree. Moreover, the developers are proud of their bikes, actively share them and share them on github, demonstrating at least the presence of a ton of free time! Honestly, it seems to me that most of these “bicycles” turn out to be either “Hello World” level projects with the goal of learning something, or as in that joke: “We don’t remember why we invented a billiard ball from which hair grows, but it was hellishly complicated. ”
In my presentation, as a pragmatic developer, I discuss the questions that a “cyclist” or a “cyclist” team lead should ask before going to the Tour de France. I will give examples of libraries and frameworks, the appearance of which was, in my opinion, justified and motivated by a pragmatic approach, as well as provide examples of creations, the occurrence of which I can not explain, on the basis of pragmatic considerations.
3. Vyacheslav Lapin, EPAM - «Hacking" entry curve “”
The invention of “bicycles” is a great way to learn! Beginning artists mostly copy the paintings of masters, so why is IT NIH syndrome considered evil? Indeed, in order to understand how a library or framework works, it is best to try to solve the problem that they solve on their own by writing, as a rule, something like that.
Since then, when our industry abandoned the model “got an education - went to work using the accumulated knowledge base until retirement”, and switched to a model of constant, permanent training (in fact, training and work became one, single process), bicycle building is perfect for us This is supported, in fact, making up the essence of the practice in training - we read tutorials, articles, watch speeches at conferences and try to try some of this in our combat projects, thus finding the shortest path along the “curve ode ”to a new technology for itself.
However, often this is not the shortest, cheapest and safest way to solve the problems of the customer’s business, so a rare customer will agree to this. Where in this situation to go to the "poor developer" - this will be discussed in my report.
→ Registration
→ Live Broadcast