[HN Gopher] It's OK If Your Code Is Just Good Enough
___________________________________________________________________
It's OK If Your Code Is Just Good Enough
Author : Vatavuk
Score : 60 points
Date : 2023-11-11 21:20 UTC (1 hours ago)
(HTM) web link (shiftmag.dev)
(TXT) w3m dump (shiftmag.dev)
| mupuff1234 wrote:
| I wonder what's the median life expectancy of a piece of code.
| biscuits1 wrote:
| Two years, maybe.
| dboreham wrote:
| 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.
| amiga-workbench wrote:
| The worse it is, the longer it will linger.
| coffeefirst wrote:
| At least for my own code, I'm pretty sure its an inverse
| relationship to quality.
|
| The masterpiece I fretted over for endless hours is guaranteed
| to be obsolete within 1 year.
|
| The crappy hack with the comment that says "@TODO make not be
| garbage sorry" is cursed to live on for eternity.
| silasdavis wrote:
| Only the good die young
| kevlened wrote:
| https://xkcd.com/2730/
| wvenable wrote:
| It varies pretty wildly but in my career a lot of code has
| lasted over 10 years and in some cases over 20. Also because
| code is sort infinitely copyable some code just keeps moving
| from product or product. Or some design moves from product to
| product. The longer you work in programming the more you have a
| set of tools that you can reach for over and over even if
| you're effectively writing it from scratch each time.
|
| I think good code is vital to the software development process.
| It doesn't have to start out good but it should end good.
| Because you're going to be back at this code over and over. A
| little bit of effort up front can save you a lot of time in the
| long term.
| PartiallyTyped wrote:
| Unless the code is running on critical systems that put human
| lives at risk, good enough is the perfect amount of good.
|
| Getting things done is more important. Excluding above scenario,
| either you will make mistakes, or you are not tackling meaningful
| tasks. And that's okay. Allocate time for clean up when there's
| less ambiguity. The more you explore the problem, the better the
| issues become.
|
| First implementation will always be bad, so throw it away and
| build something that's good enough to get the job done and uses
| what you've learned as you explored the space.
| Kinrany wrote:
| Code quality is for developers, not end users. It's fine for
| code to be atrociously structured if _literally_ no one is ever
| going to read it, even in medical devices, as long as it works.
| jackblemming wrote:
| > Take a look at the infobip-spring-data-querydsl library.
|
| That looks like an absolute nightmare and not an example of very
| good code.
| realusername wrote:
| That's also what I thought as well. This is the kind of
| overabstracted code Java gets a bad reputation for and I would
| not want to maintain that.
| klodolph wrote:
| I 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. After you ship, you're in a good position to
| revisit some of the decisions you mode. Everything's fresh, and
| you can go in and squash some bugs that you know are in there,
| expand some tests that you knew weren't as thorough as you
| wanted, and trim some of the crap that you realize that you don't
| need. Maybe it's time to do some refactoring, now that you have
| the big picture. Maybe it's time to chase after some performance
| improvements. Maybe it's time to make the integration tests
| faster and better.
| rudasn wrote:
| Agree. I always try to remind my self:
|
| - make it
|
| - make it work
|
| - make it fast
| contravariant wrote:
| Make it last?
| gavinhoward wrote:
| Upfront, I mostly agree with the post.
|
| However, I may be a tad famous about striving for perfection in
| my code. [1] [2]
|
| Why? If "good enough" is good enough, why do I go further?
|
| For a few reasons:
|
| 1. I want the industry to be more _professional_ [3] where it
| matters, and I need to set an example.
|
| 2. The kind of software I write already has alternatives, so mine
| needs to be _far_ better to get adopted. And it does. [4]
|
| 3. Also, I am just a perfectionist. It's a problem.
|
| Anyway, "good enough" is good enough _most_ of the time; just
| make sure that your situation doesn 't require more.
|
| [1]: https://gavinhoward.com/2019/08/why-perfect-software-is-
| near...
|
| [2]:
| https://git.gavinhoward.com/gavin/bc/src/commit/22253a3a6/ME...
|
| [3]: https://gavinhoward.com/2022/10/we-must-professionalize-
| prog...
|
| [4]: https://gavinhoward.com/2023/02/my-code-conquered-another-
| os...
| 3cats-in-a-coat wrote:
| Yes let's happily dive & swim in the sewer of mediocrity that is
| the modern software industry. Our hardware keeps getting better
| and better and our devices become slower and slower, while the
| apps keep glitching and crashing at an ever increasing rate.
|
| It's like the fat acceptance movement "it's OK if you're plus
| sized, or plus plus plus sized, or I guess multiply exponent
| factorial sized".
|
| But it's really not OK. Not just apps but even our operating
| systems have turned into layer upon layer of unfinished and half
| forgotten features that sum up into something literally worse
| than what random natural selection wrote in our DNA. That's
| right. Random chance, throwing crap at the wall is better than
| our "software engineering".
|
| Be better.
| harryvederci wrote:
| If you haven't seen Jonathan Blow his talk about preventing the
| collapse of civilisation, you are probably his soulmate.
| stathibus wrote:
| Somehow 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.
| savanaly wrote:
| > 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.
| jodleif wrote:
| Your users won't but your colleagues (and future you)
| definitely will
| BoorishBears wrote:
| 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.
| WalterBright wrote:
| > 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
|
| The development of an engineer:
|
| 1. newbie - follow the rules because you're told to
|
| 2. master - follow the rules because you understand them
|
| 3. guru - break the rules because your knowledge transcends
| them
|
| I often see code that follows the rules right into a swamp.
| Your example is a fine illustration of this.
| thdc wrote:
| 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.
| dataflow wrote:
| You can change the definition but you change the fact that
| those "users" aren't paying you.
| thdc wrote:
| You are correct that good code does not translate directly
| into revenue, but it affects it indirectly e.g. through
| ease of future development, maintenance, and fixes.
|
| If the thing being written is not going to be updated at
| all, then, sure, quality is not important.
| stouset wrote:
| Every coworker I've had who thinks this way has left a
| minefield of gotchas and inscrutable interdependencies for
| the unfortunate developers who come after.
|
| Yeah they "got it done" but we spend 80% of our time
| fighting fires and the 20% left on new development takes
| ten times longer than it ought to because zero thought or
| care was put into anything other than "it works for me".
|
| This to me is the difference between _engineers_ and
| _programmers_. Programmers can get something done and out
| the door, but engineers can build something that is easy to
| iterate on and easy to reason about.
| aethr wrote:
| Different 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.
| shoo wrote:
| Reasonable 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.
| xnx wrote:
| 1) Make it work.
|
| 2) Make it right.
|
| 3) Make it fast.
| morelisp wrote:
| Then some jackass who doesn't know an std::int32_t from a
| *std::basic_string_view demands you cut off somewhere around
| step 0.99.
|
| Meanwhile if you 2) 3) 1), you get cut off around step 2.99 and
| everyone's life sucks less.
| morelisp wrote:
| I mean yeah definitionally sure, but also have some goddamn self-
| respect.
| corethree wrote:
| Not to mention Perfection is defined differently be everyone.
| It's all opinion, someone's "perfect" code is another persons
| shit code.
|
| And it's not even just different among people. Along the time
| dimension your perfect code can become bad later as requirements
| change and things evolve you may realize that what was once (in
| your opinion) perfect code was actually a very bad way to
| incorporate a certain feature.
|
| Think of perfect code as a controversial literature novel. There
| is literally no point in building perfection unless your goal is
| only to build perfection for yourself rather then a
| customer/audience.
| pil0u wrote:
| My formatted-by-productivity-standards brain agrees, my heart
| disagrees.
|
| I enjoy the art of programming. I love to think that, for certain
| types of projects, I am allowed to aim for and reach perfection.
|
| My vision of perfection is not yours, so what. If your "good
| enough" is actually your perfection because of business impact,
| user happiness or optimal time management, good for you. Just
| don't tell me that _my_ perfection does not exist.
|
| Sometimes, it's good to know that you can do something just for
| the beauty of it, and programming could (should!) be one of them.
| javaunsafe2019 wrote:
| The funny thing with this is, that often times someone's
| perfect is someone else's future headache.
| andirk wrote:
| There are often 2 consumers of your code: users and developers.
|
| If a developer can write error-free binary code that improves
| performance (as seen by the user) by 0.1%, BUT the next developer
| (or even the same dev months later) can't adjust the code without
| all hell breaking loose, then that code is basically awful.
|
| Side note: add your newline at the end of your files before
| commit! Ugh
| sublinear wrote:
| > Good enough code is a nice middle ground between implementing a
| feature fast and maintaining the code quality.
|
| For something to be "good enough" it still has to be good. This
| feels like evil propaganda aimed at the poor souls who work for
| cash-strapped and inexperienced entrepreneurs.
|
| Implementing a feature fast is no excuse for writing crappy code.
|
| There are many sets of constraints to satisfy when you're writing
| code. I agree chasing "perfection" is pointless, but too often
| you see inexperienced people rationalizing their shoddy work. If
| you're excusing yourself from bothering with crazy optimizations
| that have little to no business impact, fine it's good enough. If
| you're excusing spaghetti, you're the inexperienced person I'm
| talking about. The "good enough" example from the article sounds
| like spaghetti.
| gary_bernhardt wrote:
| This is a great excuse to repeat one of my favorite quips, from
| the late Jim Weirich (from memory, but this is at least very
| close): "half-assed is OK as long as it's the right half of the
| ass."
| manicennui wrote:
| In the vast majority of cases, writing good, maintainable code
| does not require more time. The real problem is that the majority
| of people working as software engineers barely know what they are
| doing, and use excuses like this because it makes some amount of
| sense to the incompetent managers in charge of them.
| mattgreenrocks wrote:
| > In the vast majority of cases, writing good, maintainable
| code does not require more time
|
| Yep. Especially with practice. You can pretty much get to a
| point where you build things reasonably well by default without
| even thinking too hard about it. You have to want to attain it,
| and be willing to ruthlessly evaluate and file down your design
| repeatedly.
|
| I believe there's a compounding effect at play here, which
| accounts for super-linear gains in ability, given enough focus,
| time, maturity, and number of projects.
| BlackjackCF wrote:
| I equate it a lot to writing an essay. Once you've gotten
| enough practice, you know the general structure. You'll write
| a draft and then do some edits with some red ink. Then, if
| you have people willing to reas it, you get their eyes on it.
| Tade0 wrote:
| This.
|
| And it's often simple techniques like preferring pure functions
| or using immutable data structures that enable a huge
| improvement in maintainability, yet few seem to be employing
| them.
|
| Occasionally the difference comes purely from the fact that
| someone looked into the library docs and chose the appropriate
| API method.
| mattgreenrocks wrote:
| Okay advice for day-to-day, but, horrible advice to take over the
| long term. Just Good Enough isn't going to improve your skill,
| it's going to keep you exactly where you are.
|
| Your code is a distillation of how well you understand the
| problem and how it's being solved. Confusion usually means either
| the requirements are not well-understood, you still have
| unknowns, or you simply don't understand the problem/solution
| well enough to express it to both humans and the computer
| fluently. All of those involve thinking more and getting more
| information.
|
| Really, I write the best code I can given the circumstances so I
| don't have to keep coming back to the same section of code over
| and over. I want to solve it as well as necessary and move onto
| something new.
|
| Also, why is the tech industry so weird in how it continually
| feels the need to degrade the importance of technical skills? Is
| it seen as taboo that there are still large differences in
| individual programmer skill?
| fragmede wrote:
| no, but until recently, programmers were not known for their
| social skills, and as such, differences in individual skill
| levels was not handled in an emotionally mature way, resulting
| in unhealthy, bordering on toxic, environments. it's not taboo,
| but it's maybe unsavoury to some
| ozim wrote:
| I think it is super hard to make world where only best
| developers are working.
|
| You need huge numbers of average developers to keep running all
| the software there is.
|
| Just like in army, average Joe can be a soldier because there
| will never be enough "best of the best" to have an army of only
| special forces.
| andrewstuart wrote:
| How good your code is depends entirely on context and priority.
|
| Context and priority should be defined for a project, not just
| left to the decision of each developer.
|
| I am building code for a startup right now. The context and
| priority is to "get the damn thing working". Thus code quality is
| largely irrelevant - this codebase is flat out garbage - it is
| full of commented out code, duplication, files that were obviated
| ages ago. It is unstructured, disorganised, uses different
| approaches to solving the same problem all over the place - there
| are ZERO tests, no CI/CD, the code is uploaded directly to
| production. This is exactly the right way to build this because
| none of those "terrible sins" matter when you have no customers
| and your only goal is to get something working as fast as
| possible and every secong spent making things nice is a waste of
| time and money because if the business fails then every second
| spent making things nice was wasted.
|
| If however I was working for Nasa on code that was running a
| rocket launch system, then hopefully it is stated to all
| programmers working on the system that reliability is priority
| one. This informs every about how the code is written from that
| point. It means few lines of code, alot more eyes on the code,
| must more rigorous quality control and much lower overall output.
|
| If however I was working in an ordinary business making a CRM
| system then the stated priority I imagine would be something like
| "we want a balance between productivity, reliability,
| maintainability" etc. This explicit definition of the context and
| priority sets the scene for how the code will be written.
|
| I've never worked anywhere that is was explicitly stated across a
| range of parameters what the code should prioritise in terms of
| security/reliability/performance/maintainability/time to
| market/quality etc.
| Buttons840 wrote:
| > This is exactly the right way to build this because none of
| those "terrible sins" matter when you have no customers and
| your only goal is to get something working as fast as possible
| and every second spent making things nice is a waste of time
| and money because if the business fails then every second spent
| making things nice was wasted.
|
| There's a lot of truth to this, but I would also like to see
| companies, and possible even individuals in the most negligent
| cases, be held liable for damages that come to customers when
| security breaches happen.
|
| We wouldn't build a bridge with that attitude: "Just scribble
| whatever on those plans! We need to get this thing built right
| now! None of this matters if the bridge doesn't exist and
| people aren't drive across it!" For the same reasons we
| wouldn't do this with a bridge, we shouldn't do this with
| software, although to a lesser extent.
| kylecazar wrote:
| Agreed on accountability to security breaches.
|
| The bridge analogy is good but when building a bridge you
| know people will use it, and that it won't be demolished in a
| year. I think OP's argument is that we don't have such
| assurances with MVP code, so time to launch is the only
| metric that really matters.
| renewedrebecca wrote:
| I've never seen a PoC that was allowed to have the time to be
| cleaned up properly to make it to the Good Enough phase.
| Management types tend to want to take the PoC and move it
| directly to production and assume you're incompetent if you push
| back.
| yarg wrote:
| At the time of initial integration, sure. But if it's only good
| enough when you write it, it's on a rapid path to becoming
| technical debt - and that's just not good enough.
| zenbowman wrote:
| Things like large functions or code duplication are not
| necessarily bad in the first place. A far bigger problem that I
| encounter regularly is the invention of extreme layers of
| abstraction to avoid a small amount of copy-pasting + edit in the
| name of DRY.
|
| But an even bigger problem is lack of understanding of the
| problem domain and a lack of documentation on how you plan to fix
| the problem.
___________________________________________________________________
(page generated 2023-11-11 23:00 UTC)