[HN Gopher] You will never "fix it later"
___________________________________________________________________
You will never "fix it later"
Author : kiyanwang
Score : 76 points
Date : 2022-11-20 19:10 UTC (3 hours ago)
(HTM) web link (uselessdevblog.wordpress.com)
(TXT) w3m dump (uselessdevblog.wordpress.com)
| Helmut10001 wrote:
| I think this is perfectly natural - some ideas never manifest or
| are convincing enough to publish, or sometimes you write code and
| it turns out not to be used - why produce production ready code
| in this case. I have a python package that I slowly developed
| over 5 years, step by step [1]. Everytime I use it, I find many
| things that I could develop, some I do right then, others I leave
| for later. I also have a blog [2] - you can see three dates for
| each blog post:
|
| - the time I first started working on it
|
| - the first time I published it
|
| - the last time it was updated
|
| All of these dates are important. Between start of writing and
| publishing, easily a whole year can pass. Think of doing things
| more like a process of chained events, not like a one-stop thing.
|
| [1]: https://github.com/Sieboldianus/TagMaps
|
| [2]: https://du.nkel.dev/
| jdoss wrote:
| My go to rule in engineering management is "we'll fix it later".
| I helps with my own anxiety about not having the best possible
| technical implementation and it helps ensure my teams don't feel
| totally stressed out with having everything perfect. If it works,
| we ship it. If it breaks, we iterate on it and fix it. The key
| here is to make time for things to be fixed. That is my second
| rule in engineering management.
|
| Give yourself and your coworkers some grace. Most of us are not
| writing software that has to be 100% perfect otherwise someone
| dies.
|
| So we're not lying to ourselves here. Most of the time we don't
| have to fix it later because it is good enough to get the job
| done. This mantra also helps when working with others that do
| things differently than you would have done. Does their
| implementation work? Yes. If it breaks or isn't 100% the best
| solution right now, we'll fix it later.
|
| Also, saying "bad code" is highly subjective. I wouldn't call any
| code that is in production inherently bad. It just needs to be
| fixed later. :)
| dgeiser13 wrote:
| So no one is allowed to have ideas about activities to do unless
| they have the time to fully implement the idea? Seems odd.
| faizshah wrote:
| My workflow is such that if something isn't broken but I know it
| is somehow an issue (clarity, style, etc.) then I just save them
| in a notes file. Eventually a few weeks later I collect up enough
| of these small issues and then resolve them in bulk. I do this
| for CR notes when people write non blocker comments I say I will
| fix in a follow up.
|
| My coworkers take the same view as the author in that they think
| you'll never "fix it later" once the code is committed nobody
| will ever get back to it. But I prefer doing it this way because
| the overhead of constantly going in to correct my code for small
| unimportant things is a waste of time I would rather resolve them
| all in bulk.
| peteradio wrote:
| Have you ever gotten in trouble for not working on "ticket"
| items. There are some places that managers will jerk your leash
| for working "whatever you want".
| random_kris wrote:
| I make it a point on our planning sessions and reserve a task
| here and there for things like this. Or explicitly plan a
| task to be done in quick& dirty way and acknowledging we will
| another task to clean it up later. Works great for me
| tonightstoast wrote:
| At a previous startup we had "bug bash Fridays" where we
| would either let the devs find bug tickets in Jira that
| they wanted to fix or could self report problems that they
| had noticed. While most devs don't seem to enjoy fixing
| bugs, this was shockingly well received and good for
| morale.
| mpolichette wrote:
| If you don't fix it... and the code is working... what is the
| problem?
|
| I leave notes like that sometime as indicators of intention... or
| invitation to the next reader... but if it never changes and is
| not causing issues... that's fine, leave it as is.
| simplotek wrote:
| > If you don't fix it... and the code is working... what is the
| problem?
|
| Because most of the time your hack only works by accident, or
| doesn't handle expected corner cases, or leaves out important
| use cases, or is a ticking time bomb.
| drewcoo wrote:
| "born in a house with the television always on"
|
| That's a Talking Heads lyric and not a point of fact.
| hamburglar wrote:
| If you're regularly encountering or writing code that only
| works by accident or doesn't handle important use cases, it
| isn't the fault of a TODO. A TODO should document something
| that has been considered and would potentially be an
| improvement, but is not currently necessary. It isn't
| supposed to be a flag that says "warning: I'm checking in
| broken code." If the accompanying code is actually deficient,
| reject the PR.
| simplotek wrote:
| > If you're regularly encountering or writing code that
| only works by accident or doesn't handle important use
| cases, it isn't the fault of a TODO.
|
| You're confusing a symptom with the root cause.
|
| TODO items are symptoms of a problem, one which can and
| does often manifest in code that is brittle and only works
| by coincidence.
|
| > A TODO should document something that has been considered
| and would potentially be an improvement, but is not
| currently necessary.
|
| Not really. A TODO is just a comment someone decided to add
| because at the moment they spotted something that might
| require some work, but couldn't be bothered to track it as
| a work item. Just that, nothing more.
|
| > It isn't supposed to be a flag that says "warning: I'm
| checking in broken code." I
|
| Except it actually is supposed to be a flag that states
| "yeah I know this is broken code but trust me I'll get
| around to really fix it at some time between not now and
| never"
|
| I've lost count of the age-old TODO items I stumble upon on
| projects I've worked on that served no purpose other than
| either stating "I think this needs fixing but I can't be
| bothered to track work items in a ticket" or "I just need
| my PR to go through, trust me bro I'll do this right once I
| remember to fix my shit"
| mopsi wrote:
| > _If you don't fix it... and the code is working... what is
| the problem?_
|
| It may be very inefficient, for example. Works now, but may
| unintuitively slow down when dealing with workloads that looked
| very far-fetched at the time.
|
| I have inherited a really nice C++ codebase from 1980s that
| contains warnings for Year 2038 problem and all sorts of other
| potential issues, and I can't thank those engineers enough. So
| many times I've dug into a problem or started implementing a
| new feature only to discover that someone had already thought
| of that and left useful pointers in comments.
|
| Whatever version control or note-taking applications they
| might've used instead, I doubt I could even run or open their
| files 30+ years later.
| philipwhiuk wrote:
| Sounds like there's no problem with //TODO: Fix later then if
| it's actively helping you.
| DerekL wrote:
| Title has a typo: it's missing "will never".
| dang wrote:
| Fixed now. Thanks!
| philipwhiuk wrote:
| 70 minutes later.
|
| Any longer and it would never have been fixed ;)
| giantg2 wrote:
| I installed a wall mount TV 3 years ago. The holes in the bracket
| and stuff didn't line up with the overall wall dimensions nor the
| studs. It was about 1.5" off center and about 1/8" lower on one
| end.
|
| I just got around to installing a better bracket so it's centered
| and level.
| [deleted]
| gw98 wrote:
| _I_ will fix it later. _My colleagues_ probably won 't.
|
| This is a common failure mode I've seen of development teams.
| There is no time to fix it later.
| drblast wrote:
| Except sometimes you do fix it later.
|
| Approve the PR when there's a bug/task filed to fix the thing
| later and then prioritize that work as necessary.
|
| Just as bad as never fixing things later is never releasing
| anything until it's perfect, which it never is.
| LAC-Tech wrote:
| I have and I will. You don't know me son.
| angarg12 wrote:
| Although I sorta-kinda agree with the sentiment, I disagree with
| the pessimistic conclusion (for a change!). I don't believe the
| alternatives are "fix it now or never". And we can structure our
| workflow to deal with this better.
|
| In my current team whenever this comes up, if the hack really
| needs to be shipped now and fixed later, we create a ticket
| describing the task in our queue. Periodically we timebox periods
| of time to go through the backlog and fix these little
| annoyances.
|
| It's not perfect, but it brings the "never" to a more realistic
| timeline - at least for the most important fixes.
| jasonlotito wrote:
| This is going to happen. The best way to handle this inevitable
| occurrence is to ticket this. The reviewer should ask for the
| ticket, and have the ticket linked. The ticket should ready to
| go, and the author of the code should have it ready to go as the
| "next thing" to get done, whether that's the follow up, or it's
| getting picked up in the next sprint so it doesn't get missed.
|
| The code reviewer should also watch that ticket, and be prepared
| to assist it pushing it through.
|
| If you just leave the task in the code, it will get lost. And, on
| occasion, the pressure of needing to write a ticket will get
| someone to just make the fix instead of having to create the
| ticket.
| tsimionescu wrote:
| My experience is the precise opposite. Engineering tickets with
| no clear business value rot by the hundreds in sine corner of
| the backlog, at best being brought up occasionally as an "I
| told you so" when the business case does rear its head.
|
| In contrast, people working on the code for other reasons will
| notice a TO-DO and be much more likely to bring it up _today_ ,
| as some kind of "if I'm going to do changes in that area, I
| should also address this TODO, it will just take an extra
| $days". Or at least, it will guide them to the source of a long
| forgotten bug.
| mjr00 wrote:
| This is why I set up linting rules to error when people push
| "TODO" comments.
|
| Either just do it, or put a work item in the place where you
| _actually_ track work (Jira or equivalent) so it has at least a
| chance of getting done. Otherwise you 'll end up with the typical
| 5-to-10 year old TODO comment from a completely different era
| that helps nobody.
|
| If you're going to leave a comment, leave context around why the
| hacky solution was chosen at the time of writing, and why you
| didn't do the "correct" alternative.
| civopsec wrote:
| Some things can't be done right now. Maybe the implementation
| depends on something else that isn't done yet (perhaps by
| someone else). And maybe I know exactly where I need to do the
| work. Then a todo in the comment with a ticket id is better
| than just a ticket with a completely informal hyperlink to the
| place in the code where the comment would have been.
| jll29 wrote:
| I like the suggestion to convert a TODO comment into a JIRA
| action, or supplement the former with the latter. This permits
| paying attention only to the TODOs, and to discuss them and to
| prioritize them without first having to run a monster grep job.
| marginalia_nu wrote:
| Depends on how you use it.
|
| A few years ago I used to have an IDE template that was like
| // TODO ($username $date)
|
| It was great and a central part of my work flow. I'd just leave
| them in the code whenever I saw something that needed fixing or
| could be improved, and every once in a while I'd just grep for
| this string and get _my_ todos.
|
| Some stuff was urgent, some was to be fixed later. Some never
| got fixed, but because it was all timestamped, it was easy to
| identify and clear those out. Also saved my coworkers the git
| annotate archeology to figure out who wrote the TODO and if
| they wanted additional context.
|
| This flow felt extremely productive. Being able to just drop
| these when you think of something reduces the context
| switching. It also becomes an implicit bookmark as to the code
| the remark applies to (unlike jiras that are typically not well
| integrated into the code). Creating a jira is either an
| expensive context switch, or something you postpone and
| typically forget when you're done with the task and even if you
| don't, you've wasted a lot of cognitive energy keeping this in
| the back of your head all day.
| nurbel wrote:
| Sounds like you had a workflow that you felt and still feel
| good about, why did you stop doing it?
| marginalia_nu wrote:
| Moved to a project that was incompatible with the IDE I was
| using. The new IDE lacked solid support for ad hoc named
| templates and provided no suitable tools for monitoring
| grep patterns.
|
| This added so much friction I stopped doing this.
| kevin_thibedeau wrote:
| This is why I use FIXME exclusively and always include a
| constructive description of what needs to be fixed. I sweep
| through the code before a commit to resolve easy FIXMEs and
| minimize what ends up in the repository.
| davidmurdoch wrote:
| I like both at the same time. A TODO and an issue, and the Todo
| has a link to the issue, and the issue had a permalink to the
| TODO line. Sometimes the TODO gets done during a refactor or
| otherwise, so having the comment with a link ensures the
| corresponding issue gets closed.
| saghm wrote:
| Yeah, this is how most of the teams I've worked on have done
| things. `TODO` is only allowed when accompanied by a link to
| a ticket, and people are expected to (and do!) enforce this
| when code reviewing.
| wtetzner wrote:
| I do both: put a TODO in the code with a ticket number.
| // TODO (<ticket-number>): Foo should be frobnicated
| mrkeen wrote:
| It loses too much context in Jira. Could stay permanently
| beyond the Jira event horizon (since more tickets flow into the
| Jira than flow out). Or it could get culled in a grooming
| session ("Haven't seen the bug happen in a while. If someone
| complains we'll reopen").
| quonn wrote:
| This is a good way to loose valuable knowledge. People will
| just commit without the TODO. In fact many won't even have
| thought of the TODO in the first place, because they were not
| aware of a potential pitfall. Be happy if you get a TODO, if
| you don't it will work but not as well.
| rhaway84773 wrote:
| I find TODOs useful even if the fix is never implemented as
| long as there's a proper explanation for the TODO especially
| when I'm reading the code as it explains why something
| expected isn't happening. It was simply not implemented as
| opposed to being a bug.
| simplotek wrote:
| > This is a good way to loose valuable knowledge.
|
| It really isn't. If you have anything relevant to add
| regarding your hack, post it in the ticket. That's the first
| thing that will be read when someone picks it up. Otherwise
| you're just polluting the code with good intentions.
| lifeisstillgood wrote:
| I agree with the OP - you have _immediately_ lost the
| linkage between the lines of code and the problem
| description - maybe you put a reference to the lines /
| modeule in the ticket but really, why bother.
|
| You could do "TODO fix the foobar because flange see Ticket
| 1234" (and I have a todoinator to automate that but I think
| a ticket should be more meaty than a todo but perhaps I am
| fooling myself
| simplotek wrote:
| > You could do "TODO fix the foobar because flange see
| Ticket 1234"
|
| No, you should create Ticket 1235 - fix foobar, add
| additional info such as rationale and the definition of
| done, and add Ticket 1234 as related/blocks.
| convolvatron wrote:
| how am I going to know there is such a ticket when I'm
| looking at the code?
| convolvatron wrote:
| you really have this all figured out don't you. I use TODOs
| for structural changes, not for stuff that I know has
| obvious flaws. TODO - this would be much
| cleaner if we merged it with the hash support from
| target.cc
| [deleted]
| bodangly wrote:
| What happens when the company decides to migrate from JIRA
| to something else? It wouldn't take any special effort to
| migrate the TODO but in my experience the old JIRA is going
| to be stale and abandoned entirely in a year. No one will
| even remember or think to look back at it, and new hires
| won't even know it exists.
| postalrat wrote:
| Do you have some way to link the code that's visible on
| your screen with tickets in jira? I don't. That's why I
| sometimes use comments.
| simplotek wrote:
| > What happens when the company decides to migrate from
| JIRA to something else?
|
| Aren't you grasping at straws? How many times do you
| believe a project changes it's ticketing system? So far I
| saw that happening a grand total of zero times.
|
| Meanwhile, I've repeatedly worked on legacy projects
| which have decades-old TODO/FIXIT items, which serve no
| purpose other than being noise and serving as topic in
| water-cooler shit chat.
| pstric wrote:
| I've worked on legacy projects which have decades-old
| tickets.
| dotancohen wrote:
| Open Office changing ticketing systems three times. The
| first time I copied over a few dozen of my most important
| bugs, the second time I copied over the absolute most
| important bugs, and the last time I did nothing.
|
| Nobody was reading, triaging, or fixing them anyway.
| sokoloff wrote:
| I think we're on our 4th or 5th ticketing system over 15
| years. (We're also on our 3rd revision control system,
| but the code and comments obviously migrated seamlessly
| across both of those transitions.)
| lazyasciiart wrote:
| Really? My company is on its third ticketing system.
| simplotek wrote:
| > Really? My company is on its third ticketing system.
|
| Your company should get it's shit together, unless it's
| in the business of switching ticketing systems.
| bluGill wrote:
| Ticketing systems tend to increase in price over time. I
| know one nameless company looking to migrate after their
| current system increased in price. Open source isn't any
| cheaper, you still have to pay admins.
|
| Though one other reason to migrate is the forms are
| complex and full of required fields nobody understands.
| Migration will get you past that to what matters, but
| only for a few years before the groups that required
| those fields in the first place come back and demand it
| with the same good but forgotten reasoning as the first
| time. If this is you, get your act together.
| Supermancho wrote:
| > Aren't you grasping at straws
|
| That is being generous.
| eyelidlessness wrote:
| There's definitely lost _linkage_ of knowledge if you can't
| reference the ticket from your editor, which for many if
| not most workflows means you never can. The loss is that an
| unadorned hack may have a corresponding ticket, with no way
| of knowing there's even anything to look for. The workflow
| challenge is chicken-egg: people seldom file a ticket on
| _proposed, unmerged changes_ , and most teams would balk at
| the concept without specific procedures in place; people
| definitely don't go back after a change is merged to
| annotate a hack with whatever ticket was filed for
| posterity.
|
| IME, a better solution is keeping the TODOs (or FIXMEs or
| whatever your preferred label[s]), with linter rules to
| require _aging them_ so they must be addressed _eventually,
| somehow_. Even if you address them by removing them. At
| least then there's some possibility of relinking them
| later, tied directly to the commit history.
|
| I agree with your point about polluting the code with good
| intentions, however. And I agree with the article author's
| point that most of the time you'll not go back and fix it.
| Those points combined suggest that most TODOs should
| actually just be explanatory comments. In fact, as someone
| who writes very few code comments, I think a good heuristic
| for when to write them is my usual "does someone need this
| explained?" (either by my anticipation or by their direct
| questioning) plus "would I be inclined to write a TODO
| about this?"
| randomdata wrote:
| _> If you have anything relevant to add regarding your
| hack, post it in the ticket._
|
| Presumably your integration will automatically create a
| ticket from the TODO. There is already a linting
| automation, per the original comment. No reason to stop
| there.
| simplotek wrote:
| > Presumably your integration will automatically create a
| ticket from the TODO.
|
| Creating the ticket tracking a work item is known for
| creating the ticket that tracks work items.
|
| The process is also the epitome of automation, because it
| requires zero automation to filter TODO items and only
| requires clicking on a button to create the ticket.
|
| There is no salvageable excuse for this nonsense. Work
| items are created in tickets. TODO items just track
| copouts and noise.
| randomdata wrote:
| The TODO serves as a ticket. If you have to interface
| with non-developers who can't function without pretty UIs
| then your automation can duplicate the information into a
| ticketing system, but otherwise a TODO is all you need;
| right in the place you want it.
|
| If it is going to be one of those things you never
| intended to fix, then feel free to not mention it
| anywhere. Not even a ticketing system benefits from
| tickets you don't intend to fix. Something you don't
| intend to fix is noise anywhere it ends up.
| nsxwolf wrote:
| Often when I write a TODO, it's because it's because I'm
| not going to remember to write it down anywhere else. I'm
| certainly not opening JIRA for it, so this is as good as
| it's going to get.
|
| Every once in awhile we grep through the TODOs and see if
| we should write some tickets from them. Works fine.
| lazyasciiart wrote:
| I write TODO for something that would be too disruptive
| to do as part of the current change but nice to have
| done. E.g refactoring a bunch of files - one of them
| should be renamed but that would add every file that
| refers to it to the change and make it harder to see the
| real work done. Next time I'm in that code with a simple
| change, I can submit a rename CR that doesn't have
| anything else mixed up in it.
| simplotek wrote:
| > I write TODO for something that would be too disruptive
| to do as part of the current change but nice to have
| done.
|
| One more reason to not have a TODO item and instead track
| work on a ticket. Sneaking fixes/changes as part of other
| tickets mixes up the rationale for tickets and makes
| changes harder to track. If all you're doing is a cleanup
| then all the more reason why it should be in an
| independent PR tracked accordingly.
| simplotek wrote:
| > I'm certainly not opening JIRA for it, so (...)
|
| That's the universe telling you the TODO is useless noise
| that points to a workitem that no one, not even you, find
| it relevant enough to track or work on.
|
| When that happens, do everyone around you a favour and
| leave out the TODO comment.
| simmschi wrote:
| Hmmm, I can see why you're doing this. But if you don't trust
| TODO comments to be useful and/or addressed in a timely manner
| then having a bunch of Jira tickets won't help you either.
|
| I've made the exact same experience you describe with both
| tickets and comments. Ancient tickets, somewhere deep in the
| backlog with cryptic descriptions. Or even better, high prio
| bugs that never get picked up by the teams. Same with TODOs and
| FIXMEs.
|
| In both cases it's probably a good idea to just remove the
| perceived issue after a while. Backlog tickets and todo
| comments are not like wine, they don't age well. IMO they
| behave more like compost heaps. :-)
| lifeisstillgood wrote:
| I actually wrote "todoinator" that parses out TODO comments
| from code and presents them to you as a snagging list - we
| should definitely keep the comments in the code - ideally
| everything is in code _not_ JIRA where it really just gets lost
| or fought over by non-coders (treat anything that is not code
| as "artists impression" of future state).
| Wronnay wrote:
| I just bought a SaaS a few months ago which was initially built
| as a MVP.
|
| It was full of these "I should fix that later" kind of comments -
| they are in nearly every file...
|
| I now add new features and rewrite parts of the code from time to
| time but to be honest, some parts of the product should have been
| built in a completely different way from the beginning.
|
| This makes me wonder, how many Startups build equally ugly
| MVPs...
| philipwhiuk wrote:
| If it's not ugly you probably should have been faster to
| market.
| civopsec wrote:
| I tried to fix a "hack" (that's what it said) from some months
| ago (authored by myself) recently and I couldn't spot the hack.
| It just looks correct?
|
| Back on the backburner with you!
| glitchc wrote:
| This article seems to imply that yak shaving is better. I know
| it's not saying that explicitly, but having all functions
| implemented in an optimal way before shipping requires some
| measure of yak shaving.
|
| I would rather capture the assumptions the code operates under,
| so that when one of the assumptions is violated, the build
| pipeline throws an error.
| throwaway821909 wrote:
| Sometimes you come back to an area to fix a bug or whatever, and
| it's useful to know that the hack wasn't absolutely necessary,
| just a matter of time constraints - it may be that moving to the
| proper solution is the easiest fix for your problem, and you get
| a bit of extra confidence that it won't break something else.
| bentlegen wrote:
| While the author may never go back and fix his code later, that
| doesn't mean that everybody else does the same.
|
| If you never have to come back to "fix it", was it actually wrong
| to begin with?
|
| Personally, in my own career, I've found this "come correct"
| mindset is used to justify unnecessarily flexible solutions to
| allow for easier changes in the future ... changes that 90% of
| the time, never actually materialize.
|
| I held this mindset too when I was younger. Then I got tired of
| seeing how all my clever abstractions never actually got used the
| way I intended, and decided to get smarter about it.
| duxup wrote:
| Yup. I regularly come across my own notes "This isn't the best
| way to do this because X, Y, Z. Need to address later."
|
| Years later I'm in that code and realize that X, Y, Z never
| ever happened (even if it seemed highly likely) and that block
| of code was working just fine an folks found it easy to work
| with... I was dead wrong about being wrong.
| w_for_wumbo wrote:
| Reminds me about a part of code I wrote quickly as a POC, it
| made it's way into Production unchanged. It somehow ended up
| being the most stable feature, perhaps because it wasn't
| trying to do too much. Just what it had to do and nothing
| more.
| allenu wrote:
| I've had the same experience in my career. I really do wonder
| how much of YAGNI is only learned through experience. Earlier
| in my career, I wanted everything to be more perfect, and I
| wanted to make sure I fully designed for all eventualities in
| my code. Nowadays, I know I can program myself out of a bad
| situation if it arises, so I don't try to cover all my bases,
| but I do make sure I'm aware of what could go wrong.
|
| If I make a note to "fix it later", it just means, this could
| be bad, but might not be, so I might fix, but I might not
| either. If it ends up blowing up, it should be obvious to me at
| the point that I make the decision how bad it could really be,
| what the ramifications are, and how easy it is to fix or
| detect. With experience, you can play a bit more fast and loose
| with what you decide to do or not do, but it requires a lot of
| other skills, such as designing defensively, such that if
| something does go wrong, it's easily detected and doesn't cause
| irreversible damage to data.
| cmdrk wrote:
| "Fix it later", "TBD", "TODO" code should be treated as non-
| foundational scaffolding. Sometimes you've got to erect a
| temporary structure in order to get the ball rolling on building
| the rest of the house. Just remember to tear it down at the end.
| smcleod wrote:
| This is absolutely not the case for me and seems more individual
| to the person than a general fact.
|
| Since as long as I can remember I have added #TODO: notes
| throughout my code / scripts with comments on what could be
| improved.
|
| Have I fixed all of them? Of course not. Have I fixed or replaced
| most of them? Yes!
|
| These days I have some automation that checks through my code
| repos and logs issues for any #TODO: comments with the link to
| the line which helps me keep track of them. It works well.
|
| I know of people that aren't interested in fixing their code
| after the fact - generally in my experience they're either: A)
| Not motivated / interested in or energised by the idea of
| optimisation/performance. B) Not "allowed" to work on non-
| features (by a product owner / managers etc...). C) Simply forget
| about it due to lack of a tracking system or related exposure.
| teddyh wrote:
| "There's nothing more permanent than a temporary solution."
| ranting-moth wrote:
| The article skims over the fact that a lot of "fix later"
| problems will never have to be fixed. They might be horrible
| hacks, but then time will show that no other code will depend on
| it and it works.
|
| The mongodb example he takes is also peculiar. If it was a "fix
| later", as I understand the article they should have replaced
| mongo with a relational database very early on. That might also
| have tanked the company, if they then had to spend their time
| fighting schemas.
|
| If you commit a "fix it later" hack into the codebase, you need
| to put a comment in the code and explain what's wrong with it.
| That'll increase the chances that people at least know about your
| hack code before they start depending on it.
|
| It's expensive to fix problems that don't need to be fixed. But
| then again, it can also be an order of magnitude (or two or
| three!) more expensive to not fix a problem that should have been
| fixed.
|
| Just felt the need to rant about it now, because I wouldn't do it
| later :)
| alphabettsy wrote:
| I don't believe it's that absolute.
|
| Sometimes it never needs to be fixed later because the TODO
| solution is future proofing or over engineering that never
| becomes necessary.
| Jorengarenar wrote:
| >Compare this, written and published post, to the list full of
| "blog post ideas" that never materialized
|
| I feel called out...
| Scarblac wrote:
| To be fair my attempts at making a blog rarely make it to a
| list of ideas, they get stuck at picking a static site
| technology and theme.
| walrus01 wrote:
| The analogy that the author presents with the disassembled bed
| frame on the floor also applies to non-software projects. For
| things that are small to medium sized pieces of physical
| infrastructure, data cables, electrical wiring, etc, the "we'll
| fix it later" mentality and normalization-of-sketchy-hack-jobs
| also applies.
|
| Look at any mid size enterprise rack cabinet of servers,
| switches, routers and stuff where the cabling is an absolute
| nightmare with no labels on anything and years of stuff accreted
| on top of years of previous stuff. It never _gets fixed_ until
| something catastrophic happens.
| jimbobimbo wrote:
| "We'll fix it later" == "we shipped it like this" couple of
| months later.
| digitalsushi wrote:
| It's like that "broken window" anecdote from The Pragmatic
| Programmer's Guide...
|
| A neighborhood starts to suck once there's a broken window no one
| is fixing. You see the broken window and after a while you just
| start to think "what a lousy neighborhood". So, if you have a
| broken window, and you care about it, you should go out of your
| way to fix it.
|
| Fix the leak in the toilet. Get the bad tooth filled. Get your
| self tests running again.
| revskill wrote:
| Yeah, i've seen my teammates use this "trick" to get the pull
| request merged: By introducing more tech debts.
| [deleted]
___________________________________________________________________
(page generated 2022-11-20 23:00 UTC)