I wonder what's the median life expectancy of a piece of code.
Hard to know. I know there's plenty of code that never gets into production. Otoh there's code I wrote in 1996 that's still in widespread use.
It's OK if your code is just good enough
11–20 of 149 posts
Re: It's OK if your code is just good enough
#12I think there's a pretty wide range between 3 and 4 that is worth exploring. Maybe the real problem I have with this article is that once you peg 3 as "good enough" and 5 as unachievable, then there's a whole mess of interesting quality levels squeezed between the 3..5 range. If we peg 3 as "good enough to ship and stand behind it", then I'm immediately thinking about getting the code to somewhere in the 3.5 range. A…
Agree. I always try to remind my self:
- make it
- make it work
- make it fast
Re: It's OK if your code is just good enough
#13Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.
> Your users don't care how clean your source code is
They do care about bugs and new features though, and bad code quality will lead you to more bugs and slower shipping of features in the medium/long run. At least, that's how I define good code.
Re: It's OK if your code is just good enough
#14Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.
Your users won’t but your colleagues (and future you) definitely will
Re: It's OK if your code is just good enough
#15Different levels of code quality are important for different teams / projects. Teams that are still discovering the domain and defining patterns should aim for a lower quality so they can iterate more easily. In this mode, knowing that code was written quickly and is fine to throw away / reshape is critical. Aiming for Very Good is likely to be a waste of time here.
In other projects, the domain is clearer, or the system already has well defined patterns that should be followed. In this mode fast iteration is also possible, but it's because the code is clean and follows strong patterns making it easy to understand. Good Enough code here is quite likely to slow the team down as they grapple with needless bugs and code that's hard to decompose / refactor.
The most important aspect of quality is that the team defines the level of quality that's needed for the project or the work being undertaken, and they deliver to that. Have the conversation up front about what level of quality to aim for and why. Then the team is on the same page, and everyone can move forward with the same expectations.
Re: It's OK if your code is just good enough
#16Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.
Chasing code quality and code-quality-adjacent metrics often results in buggy apps.
Copying and pasting a line of code can become a future bug when someone doesn't refactor a line of code. But building some overwrought framework to avoid ever repeating anything can introduce classes of bugs that are much much harder to solve because of the layers of indirection.
And depending on what vertical you're in, sometimes releasing something is the best path to a more reliable app. If you're writing crud apps where 99% of the complexity is defined by business rules, getting a V1 out so you can learn all the places where the business rules were improperly captured gets you a better result than bikeshedding endlessly about having the most polished version of those broken assumptions.
tl;dr: sometimes "worse code" leads to a legitimately better end product for your users.
Re: It's OK if your code is just good enough
#17I wonder what's the median life expectancy of a piece of code.
The worse it is, the longer it will linger.
Re: It's OK if your code is just good enough
#18Reasonable engineering decisions depend on context.
POC-quality code that doesn't have clean boundaries and is tightly coupled isn't necessarily a problem if it is an internal detail of some application or library that is cheap to change in future if necessary, and its impact is localized. As long as it works, if there aren't any forces that cause it to be revisited, maybe it can be left to be low-quality forever, without any further impact.
Where things get concerning are if the cost and coordination required to change the design in future grows over time or becomes effectively impossible. E.g. if the POC-quality stuff ends up being propagated internally throughout the codebase over time as developers make changes and add it into more and more places -- maybe its within the control of a single team to fix it, but if left unchecked the effort grows from a few hours work in once place to something requiring planning, systemic refactoring, testing, dedicated effort over a period of months.
Or, worse, if the POC-quality poor design has ended up polluting system interfaces between components owned by multiple teams or multiple organizations, so removing it would become a multi-month or multi-year coordination process between groups of people with different priorities, requiring a V2 release, deprecation of V1 & migration.
Re: It's OK if your code is just good enough
#19Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.
I like to say that users includes the people working with (using) your code in the future. It changes the definition of user compared to the normal usage, but I think it's a good point.
Re: It's OK if your code is just good enough
#201) Make it work.
2) Make it right.
3) Make it fast.