Entropy is inevitable. It\u2019s everywhere we look, within everything we do. All things gradually decline into disorder. However, this does not mean we cannot fight back. But first of all, we need to make sure that we are not making things worse by accelerating the degradation process<\/a>.<\/strong> “Starting light” is the best strategy to control software entropy from day one.<\/strong><\/p>\n <\/p>\n You have an idea for a software product<\/strong><\/a> that can have an impact. You collect a team of similarly minded, technically focused people, and you start designing it. You select a programming language, a modern framework and other cutting edge infrastructure to make it happen.<\/p>\n After 4-5 months of developing you are ready to launch. “Giving birth” is full of excitement but it is only the beginning of a long journey.<\/p>\n Assuming your initial hunch was correct, people start buying your\u00a0product<\/a><\/strong>. And they start bombarding you with suggested new features. You personally also have a\u00a0list of things that you would like to add to the product. And so, in iterations, you start making your software a better fit for your customers<\/strong>.<\/p>\n There is no end to this journey. The market dynamics guide you to an endless loop of product iterations. With each one, your product becomes a bit bigger and a bit harder to manage. This is the trap of software entropy.<\/p>\n You see, with each new feature you add technical debt.<\/strong> The term is mostly used to refer to “shortcuts” when you select the fastest instead of the best solution to a technical problem.<\/p>\n However, more broadly, each new functionality is a technical debt by itself: you need to ensure that every additional feature<\/strong><\/a> works with all previous functionality and that every modification in the UI does not break customer customizations<\/a><\/strong>. This means\u00a0additional work and testing with each iteration.<\/p>\n At some point, you have accumulated enough technical debt that you start thinking of redesigning part or maybe all of your product from scratch. As new members join the tech team, they also bring suggestions about a more modern way to do things or a marvelous library that can produce improved results. Junior (but upcoming) programmers often believe in a marvelous framework or library that will save us from all our problems.<\/p>\n But you know that rarely is a new technology alone the solution to an old problem. At the same time, your problem persists: you cannot efficiently grow the product any longer.<\/p>\n