Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I think you're being too harsh on the devs implying that it's always the dev's fault for "good enough" code.
Most of the time micromanagement takes the charge and makes people achieve way too much in way too little time. Developers are stressed out already when a manager is looking over their shoulder.
Then there's the "Last minute changes before we go live" changes that massively fucks up the codebase.
The problem with good enough code really is that it works. Good enough for you to keep your job. And that's exactly how legacy codebases are born. -
"Good enough" is too vague to be used as a measure. My "good enough" now is still maintainable, understandable and does what it's meant to do in a clear manner.
"Good enough" for me 10-15 years ago was messy, ugly, 150 line methods that worked but would make even myself want to rip my eyes out when having to change or extend the functionality 2 months down the track.
Title: The problem with "good enough" code
Body:
I'm a software developer, and I've seen my fair share of "good enough" code. You know the kind of code I'm talking about: it works, but it's not pretty, and it's not very maintainable.
The problem with "good enough" code is that it's a slippery slope. Once you start writing "good enough" code, it's easy to fall into the trap of always taking the easy way out.
Before you know it, your code is a mess of hacks and workarounds. It's hard to understand, it's hard to maintain, and it's a nightmare to debug.
I've seen projects go down in flames because of "good enough" code. The code was so bad that it was impossible to fix, and the project had to be scrapped.
I'm not saying that you should never write "good enough" code. Sometimes, you just need to get something working, and you don't have the time or resources to do it perfectly.
But if you're going to write "good enough" code, you need to be aware of the risks. And you need to make sure that you're only writing "good enough" code for a short period of time.
Once you have a working prototype, you need to start refactoring your code and making it better. You need to make it more readable, more maintainable, and more testable.
If you don't, you'll eventually regret it. Your code will become a liability, and it will hold you back.
So next time you're tempted to write "good enough" code, think twice. It might save you some time in the short term, but it will cost you in the long run.
devrant