Prevent customer frustrations ⚠️😤

You can always improve, even if "it ain't broke." Your clients will appreciate it. Hey developers! There is a constant battle between “Release early, release often” (RERO) and “If it ain’t broke, don’t fix it” approaches in the dev world. The question arises whether continuous improvement is always a good thing. On the other hand, there is an unwritten rule saying "Never fix anything unless it's a problem, and you have evidence showing that the problem really exists." Let’s briefly discuss this! World of constant changes In today's world of constant change, we must learn to be agile. Cyberattackers are constantly looking for vulnerabilities, software providers are constantly releasing bug fixes and new features, and customer competition is fierce. When nothing changes, the risk increases. Keeping things the same entails taking on additional risks when systems become obsolete. However, agility has its own set of risks. Upgrades are rarely smooth, new versions frequently introduce new flaws, and unstable infrastructure can result in negative press and occasionally even expensive fines. Today we have multiple layers of complicated software bandages to keep systems compatible with dated procedures and machinery for the sake of stability. However, such alleged stability may only be apparent. It will eventually fail or cause a disaster. Change aversion By reading [comments on this topic on HN](%2F%2Fnews.ycombinator.com%2Fitem%3Fid=32950811%26utm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/pGKkfHvQHs2Ps3IQL_16Nhmw3U8=301), people are mostly change-averse. But what's interesting is that most of them also protest against bugs, outdated software versions and the like. It's a paradox that shows that people are unaware that the software can not survive without periodic upgrades. Several conflicting opinions are highlighted below: - "If you had to purchase a new refrigerator every 18 months, especially if it doesn't offer you anything new, you would be furious. It’s just like that." - “I think the idea of "if it ain't broke, don't fix it" is roughly ridiculous. Even if you don't have any bugs, the environment around you changes so fast that you sooner or later will.” - “As a developer using libraries and components, I really hate "release early and often”. As a user, I also hate "release early and often".” Opinions are obviously divided, and of course, some advocate change. Regarding that, you should pay attention to the fact that, whether we like it or not, changes are an integral part of modern life! "Never "fix" anything unless it's a problem, and you have evidence showing that the problem really exists" is simply out of date! “Release early, release often” pros The wisdom behind the RERO strategy is that it allows you to include actual user input into your development. It promotes user-centred design. RERO strategy benefits listed below are undeniable: - Rapid feedback loops boost developer output - developers are better equipped to tailor upcoming work to user needs when they receive feedback on each change or a smaller collection of changes. - Shorter cycle for feature and patch releases - releases are more closely related to requests or needs when features and patches are developed and made available fast. Additionally, frequent releases can contribute to the short lifespan of bugs. - Steer clear of heavier releases - longer gaps between releases increase the pressure to deliver substantial releases with numerous significant features. - Enhances the user experience - users are more likely to purchase active products that are constantly and consistently getting better. Better software development flexibility, happy clients, and satisfied developers result from the “Release early, release often” strategy. How to prevent failure? Up until the point where you have to upgrade, and chaos ensues… You've been dealing with problems for years. And you'll need to embark on a large project to make the update happen. The argument that you shouldn't update because it isn't broken may appear reasonable. It was becoming increasingly broken while you were doing nothing; you were simply unaware of it. Therefore, you should update everything frequently on all projects you control. If something doesn't work, you want to know as soon as possible and take action rather than wait years to find out something doesn’t work. The incremental effort required for this is minimal if you remain on top of updates like that, and things will generally work. Make "improvement" a crucial component of daily operations to embrace it. Subject prospective enhancements to automated tests using realistic synthetic workloads as they move through integration stages. Bugs should be fixed when updates are ready for production because they have undergone a rigorous testing process. Putting this perspective into practice, issues on both the "release early and often" and "don't fix it if it ain't broke" strategies are resolved. You can always improve, even if "it ain't broke." Your clients will appreciate it. Using standardized development environments, such as [those provided by Codeanywhere](%2F%2Fcodeanywhere.com%2F%3Futm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/bQK9K2FHfemufbb9vSKvRdMx46g=301), is a great way to avoid surprises in production. Furthermore, a standardized development environment allows you and your colleagues to jump in quickly and make the necessary updates. Around the web - You may discover more about testing feedback loops in the [guide about the software testing life cycle](%2F%2Fwww.sealights.io%2Fsoftware-quality%2Fan-introduction-to-software-testing-life-cycle-stlc-definition-and-phases%2F%3Futm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/J6QWULoSmgmxNhhn1hx1kbx29V0=301). - [SvelteKit](%2F%2Fsvelte.dev%2Fblog%2Fannouncing-sveltekit-1.0%3Futm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/bgzJ0m-oe8JoLLi9hxJYY2z0YWE=301) is 1.0 after two years. It's the recommended way to build Svelte apps of all sizes today. - After 20 years simulating reality, [Dwarf Fortress developers](%2F%2Fwww.pcgamer.com%2Fafter-spending-20-years-simulating-reality-the-dwarf-fortress-devs-have-to-get-used-to-a-new-one-being-millionaires%2F%3Futm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/PD6L1xzr7xSEACNABgGiyCXo-UM=301) must adjust to being millionaires. 🤑 - OpenAI's ChatGPT inspired the field. Smart, engaging. [This writeup](%2F%2Fyaofu.notion.site%2FHow-does-GPT-Obtain-its-Ability-Tracing-Emergent-Abilities-of-Language-Models-to-their-Sources-b9a57ac0fcf74f30a1ab9e3e36fa1dc1%3Futm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/HEyfO3tS7-EFEfbbXOoKZrba_8c=301) covers the GPT-3.5 model family's emergent abilities and sources. - And these are [ChatGPT's circumvention methods](%2F%2Ftwitter.com%2Fdavisblalock%2Fstatus%2F1602600453555961856%3Futm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/rjbLTi1uls5yXSGQwOtqTydNDqA=301). 😜 Talk to you soon! Mira How would you rate this email? Very unsatisfied [slightly-frowning-face.png](%2F%2Fsurvey.survicate.com%2Ffa6587214e78ec3d%2F%3Fp=anonymous%26aid=4795767%26utm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/V8u78HYiw4rvhJDkjaAM82Yym_0=301) [neutral-face.png](%2F%2Fsurvey.survicate.com%2Ffa6587214e78ec3d%2F%3Fp=anonymous%26aid=4795768%26utm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/bClkvl7lThZs2mID1LqqOJ1a6ro=301) [slightly-smiling-face.png](%2F%2Fsurvey.survicate.com%2Ffa6587214e78ec3d%2F%3Fp=anonymous%26aid=4795769%26utm_medium=email%26utm_source=newsletter%26utm_campaign=HT/1/01010185159e9f62-f1420977-e9ac-4725-8972-be7a8d329b27-000000/d-w6AT0ScBI7MTYDNcOrfcj1ohI=301) Very satisfied -- This email was sent to [{EMAIL}](mailto:{EMAIL}?utm_medium=email&utm_source=newsletter&utm_campaign=HT) because you are subscribed to our newsletter. If you do not wish to receive such emails in future, please [UNSUBSCRIBE HERE](. 😿 Copyright © 2022 Codeanywhere 2443 Fillmore St #380-7365, San Francisco, CA 94115, USA All rights reserved.