https://shiftmag.dev/code-quality-good-enough-2034/ Skip to navigation Skip to content ShiftMag Insightful engineering content & community Skip to content Subscribe Navigation * Latest News * About * Subscribe * RSS * Twitter * LinkedIn * 8.11.2023. * Productivity * Software Engineering It's OK if your code is just good enough [vgv_avatar] Vedran Grgo Vatavuk [Code-quali] Good enough code is a nice middle ground between implementing a feature fast and maintaining the code quality. [Code-quality] I've heard a story about a student who had to write an essay to pass the exam. He had a three-month deadline. During those months he struggled a lot rewriting pages again and again. Every now and then the professor checked on him and he would always respond with "I'm not done yet, it's simply not good enough". Finally, the professor suggested: "Write the essay as if it would be graded good enough". As much as this approach was strange to him, he took the advice. Surprisingly, he finished the essay in a whip earning a higher grade than expected. Where I come from, good enough would be a "three", simply an average grade on a 1 to 5 scale. Solid, acceptable, good. The five shades of code quality We, as software developers, not only write essays but dissertations to bring our pile of zeros and ones to life. Most of us would want our code to be 5 out of 5. But is this something worth pursuing? Let's explore five shades of code quality: 1 - Shit 2 - Proof of concept 3 - Good enough 4 - Very good 5 - Perfection Grade 1: Shit This is the type of code that makes you sweat. Your heart sinks when you hear about a new requirement. You know it will take up ages to implement it. The best thing you can do is to throw everything away and rewrite it. Such code shouldn't be acceptable, we shouldn't ship shit. Grade 2: PoC Typical PoC code. You know that this code is not good but you can live with it for a while. Usual problems: * doesn't have clear architecture, clear boundaries * many things are tightly coupled * many edge cases are not covered * missing validations * inadequate domain object modeling * too complex or too tiny test suite * code is not clean While this may not sound ideal, it can serve to quickly determine the direction you want to go. You can move really fast and iterate as you go. This code quality is particularly suitable for PoC initiatives. Grade 3: Good enough Good enough code is a nice middle ground between implementing a feature fast and maintaining the code quality. It addresses many of the issues typically found in grade 2 code, with some exceptions: * some unnecessary levels of abstraction * some unclear naming * few larger functions or classes (nothing too big) * misuse of exceptions here and there * some code duplications * redundant commenting * readability issues in tests This code is suited for most applications. It's probably the best for those dealing with CRUD operations. You can also achieve good results using this approach on components involved in traffic flow. Grade 4: Very good Grade 4 is a highly maintainable clean code paradise. Doesn't have any problems that good enough has. Take a look at the infobip-spring-data-querydsl library. Although it sounds perfect, it's not. Everything is by the book, yet you may not like it, or dislike some parts of it. For example, you may find interfaces to be too generic, or you might be bothered with the usage of primitives instead of objects or something else. There will always be something to dislike and that is ok. :D. The problem with this grade is that it is difficult to achieve. We have different backgrounds and views about how a really good code should look like. I've worked with a freelancing company whose code was on this level. In order to achieve it, they enforced highly strict static code analysis and really challenging code reviews. Static code analysis was the cornerstone to stop most of the common problems from good enough entering the codebase. You can view them here - under principles. Code review consisted of two reviewers, one developer and an architect, plus a QA person who would check the quality of the review. If you want to tackle with grade 4 you need to build infrastructure for it and have everyone onboard with it. Aiming for this grade will slow you down so it should be taken into consideration when doing estimations with PD. Clear benefits will be seen in the long run. This grade might be suited for building libraries that would be used by multiple projects/teams or when building critical parts of a system. Grade 5: Perfection Doesn't exist. Good enough is the way to go Daily we are faced with different requirements, different deadlines, scopes, and so on. They are, of course, not always quick and simple to solve but most of the time, the good enough approach is the way to go. To me, the code that has a clear architecture, understandable names of services, and good tests ticks all the boxes. And I like it! It doesn't have to be a clean-code candy. If you prefer candies, then you have to convince PD and your team that this extra sugar will benefit the project. What would you say, what would be your preferred coding approach? subscribe shift-mag Sarcastic headline, but funny enough for engineers to sign up Get curated content twice a month * indicates required Email Address * [ ] [ ] [Get our latest articles] [branding_l] Subscribe to the RSS feed Overview * The five shades of code quality * Grade 1: Shit * Grade 2: PoC * Grade 3: Good enough * Grade 4: Very good * Grade 5: Perfection * Good enough is the way to go Related articles The Lazy Developer: Testing in production is real, but... November 7 / Antonija Bilic Arar The Agile Manifesto has stood the test of time, says its co-author Jon Kern October 16 / Antonija Bilic Arar Are your engineering "best practices" just developer dogmas? October 11 / Alen Kosanovic The days of "it works on my machine" are gone; meet standardized development environments October 2 / Fabjan Vucina Shawn Wang on the rise of the new role: AI engineer September 21 / Ana Marija Kostanic Infobip for Developers Expand your app's reach! Expand your app's reach! Enrich your application with easy-to-integrate, secure communication APIs offering channels your customers widely use and love. Try it for free! > subscribe shift-mag --latest Sarcastic headline, but funny enough for engineers to sign up Get curated content twice a month * indicates required Email Address * [ ] [ ] [Get our latest articles] [branding_l] Written by people, not robots - at least not yet. May or may not contain traces of sarcasm, but never spam. We value your privacy and if you subscribe, we will use your e-mail address just to send you our marketing newsletter. Check all the details in ShiftMag's Privacy Notice Email is not your cup of coffee? Subscribe to the RSS feed More articles The Lazy Developer: Testing in production is real, but... November 7 / Antonija Bilic Arar [lazy-devel] The Lazy Developer pushes code to production without testing and doesn't follow security best practices. Why? Because processes and protocols slow them down. The Agile Manifesto has stood the test of time, says its co-author Jon Kern October 16 / Antonija Bilic Arar [Jon-Kern-7] Agile is not a fixed process or some training course everyone needs to go to. Are your engineering "best practices" just developer dogmas? October 11 / Alen Kosanovic [developmen] If you don't understand why a particular practice is used, you risk going down the lane of "hype-driven development". About Shift Magazine ShiftMag is a global magazine and community for developers. Whether you're a staff engineer, engineering leader, or just starting as an aspiring engineer, we - the team behind ShiftMag - want to offer you insightful content regularly. ShiftMag is launched and supported by the global communications API leader Infobip, but we are both editorially independent and technologically agnostic. * Twitter * LinkedIn Shift Conference * Zadar, Croatia, 2024 * Miami, US, 2024 Categories * API * Artificial Intelligence * Backend * Business of Software * Career * Cloud * Community * Data * Developer Experience * DevOps * DevRel * Event * Frontend * Infrastructure * Machine Learning * Open Source * Productivity * Security * Software Engineering * Sponsored * Tools * Web Development Before you go * It's OK if your code is just good enough * The cycle of engineering career development: impostor, intuition, stagnation, repeat * DORA, SPACE, GSM, or DevEx: How to measure developer productivity? * Viktor Farcic: There is no such thing as a DevOps engineer * How to implement FinOps? Make it easy for the engineers! * On everything but Kubernetes with Kelsey Hightower (c) ShiftMag, powered by Infobip. All rights reserved. Privacy Policy * Cookie Policy Return to top