- Dmitry Mamonov , Wrike "From bicycles to motorcycles: why developing your own solutions can be better than using ready-made frameworks."
- Vladimir Krasilshchik , Yandex “Welcome, or cyclists are not allowed”
- Vyacheslav Lapin , EPAM – Hacking the “entry curve”
How does the process of developing your own product differ from outsourcing projects from a technical point of view? When does it make sense to invest in development from scratch, and when is it better to take a ready-made solution?
In software development, writing your own bikes is treated as the romance of work. Programmers proudly share their bikes and post them on Github. According to the speaker, these are “Hello World” projects with the goal of learning something, or nonsense on the level of “We don’t remember why we invented a billiard ball from which hair grows, but it was hellishly difficult.”
In his speech, the speaker will discuss the questions that a “cyclist” or a “cyclist’s” team lead should ask himself before going to the Tour De France. He will give examples of libraries and frameworks, the appearance of which was justified and dictated by a pragmatic approach, as well as examples of creations, the appearance of which is impossible based on pragmatic considerations.
Inventing “bicycles” is a great teaching technique! Aspiring artists mostly copy the paintings of masters, so why is NIH syndrome considered evil in IT? After all, in order to understand how a library or framework works, it is best to try to solve the problem they solve on your own, usually by writing something similar.
Since we moved to a model of constant, permanent learning (in fact, learning and work have become one, unified process), “bicycle building” perfectly supports us in this, being essentially a practice in learning: we read tutorials, articles, watch speeches on conferences and try to try some of this in our combat projects, thus finding the shortest path along the “entry curve” into a new technology.
However, this is often not the shortest, cheapest and safest way to solve the customer’s business problems, so it is rare that the customer will agree to this. Where should a “poor developer” go in such a situation? This will be discussed in Vyacheslav’s report.
What else to read: |
---|