90% of consumers of enterprise solutions use only 5% of their capabilities<\/h2>\r\n\r\nThe problem with enterprise-level products is the large number of redundant features that developers add to them. And since any solutions need regular updates, they add more and more features aimed at a small part of the target audience.\r\n\r\nAt the same time, enterprise level products are characterized by complex code base, high reliability requirements, long development time and long exploitation period. Therefore, their manufacturers do not strive to keep up with current trends in development, but rely on stability. Often the developers of such products do not know the actual needs of users, because they do not take into account requests for added functionality from real consumers.\r\n\r\nAs a result, there is not just redundant functionality, but a set of features that only 1-5% of users need. For example, the solution of American giant VMware is a huge constructor of features, most of which are not used by ordinary consumers. And about 90% of users need only 5% of the platform\u2019s features.\r\n\r\n

Parkinson\u2019s law plus Moore\u2019s law<\/h2>\r\nParkinson\u2019s Law states that any activity takes all the time it takes. Likewise, enterprise-level software can ramp up features until they take up all the resources provided.\r\n\r\nFor a long time, Moore\u2019s Law was in parallel with Parkinson\u2019s Law. According to Moore\u2019s Law, every two years the number of transistors in chips doubles. This meant that software manufacturers did not have to think about whether there was enough performance for it. So they added more and more features without regard to the hardware\u2019s capabilities. However, Moore\u2019s Law no longer works. Meanwhile, major vendors continue to release software with redundant functionality. There may be several reasons for this:\r\n\r\n

\r\n
• due to the lack of handling requests for added functionality from customers, the developer does not know the real needs of most of their customers;<\/li>\r\n
• customers are too different and each of them needs different functions;<\/li>\r\n
• it is important for the vendor to release regular updates, adding any functionality that wasn\u2019t already in the application.<\/li>\r\n<\/ul>\r\n\r\n

  What\u2019s wrong with redundant functionality<\/h2>\r\n\r\nIt would seem that much is not little. What\u2019s wrong with a product containing some redundant functionality that may be needed in the future? There are several reasons to avoid redundant functionality.\r\n\r\nFirst, such products are more difficult to use and harder to understand. It requires several high-level specialists to work with a large number of functions. Besides, a program with redundant functions loses its lightness. It is more difficult to operate, it needs more resources, and the price of such a solution will be higher than analogues. At the same time, customers pay money for features they will never or hardly ever use.\r\n\r\n

  The solution is YAGNI and requests to add new features<\/h2>\r\n\u201cImplement only the features you really need, not the ones you\u2019ll need in the future.\u201d<\/i>\r\nRon Jeffries, co-author of Extreme Programming and the Agile Manifesto<\/i>\r\n\r\nIn response to the problem of implementing redundant functionality, the concept of YAGNI was born. The acronym stands for You ain\u2019t gonna need it or \u201cYou won\u2019t need it. At the heart of the YAGNI principle is the rejection of redundant functionality in software development as one of the core values of the product. The developer only adds features to the product that are really needed.\r\n\r\nA simple way to understand what functionality will be relevant to consumers is to process their requests to add new features.\r\n\r\nFor example, in our project we staked on the simplicity and lightness of the solution. Users decide for themselves whether they need this or that feature. The features they need can be activated and those they don\u2019t. You will only be charged for what you actually use, not for the entire package. If a client needs some extra functionality, he can make a request to add a new functionality and get it individually.\r\n\r\nThis approach allows the company to save money on unused features and still get all the functionality they need.","protected":false},"excerpt":{"rendered":"

  In this article we’ll tell you why redundant functionality is disadvantageous for users and how to avoid it.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[21],"tags":[],"class_list":["post-1939","post","type-post","status-publish","format-standard","hentry","category-virtualization"],"yoast_head":"\n