12 ms·

You will never “fix it later”

250 points by kiyanwang 4y ago

Jorengarenar 4y ago
>Compare this, written and published post, to the list full of “blog post ideas” that never materialized I feel called out...
- Scarblac 4y ago
  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.
  - Jorengarenar 4y ago
    Well, in my humble opinion, you got the order wrong then. You need to start from the idea, the "how" comes later.
    - Scarblac 4y ago
      Yeah, of course, I know. But thinking of good ideas is hard and working on the "how" somehow feels productive, so sometimes I fall into the trap.
lamontcg 4y ago
Counterpoint: it may be a complete waste of time to "fix it right" and the business may be able to sail on for the next 10 years without ever fixing it, and that may be absolutely fine. The perfect code will never ship.
voxelghost 4y ago
One way is to more or less auto-convert (//|#)TODO:, to (//|#)INFO: or (//|#)NOTE: when merging or pushing.
LAC-Tech 4y ago
I have and I will. You don't know me son.
teddyh 4y ago
“There’s nothing more permanent than a temporary solution.”
deleted 4y ago
[deleted]
Helmut10001 4y ago
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 https://github.com/Sieboldianus/TagMaps [2]: https://du.nkel.dev/ https://du.nkel.dev/
mpolichette 4y ago
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 4y ago
  > 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 4y ago
    "born in a house with the television always on" That's a Talking Heads lyric and not a point of fact.
  - hamburglar 4y ago
    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 4y ago
      > 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"
DerekL 4y ago
Title has a typo: it's missing “will never”.
- dang 4y ago
  Fixed now. Thanks!
  - philipwhiuk 4y ago
    70 minutes later. Any longer and it would never have been fixed ;)
    - dang 4y ago
      Ah drat - clearly I should have posted "we'll fix it in a bit". Oh well!
jasonlotito 4y ago
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 4y ago
  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.
  - sdiupIGPWEfh 4y ago
    My experience matches yours, and I wanted to call that out with more than just an up-vote. The ticketing system is where rework goes to die. In an engineer-led environment without a project management class calling the shots, maybe I'd feel different, but whoever is ordering the backlog is always going to prioritize features and fires, because that's what drives their own career advancement.
mjr00 4y ago
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.
- davidmurdoch 4y ago
  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 4y ago
    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.
- quonn 4y ago
  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 4y ago
    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.
glitchc 4y ago
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.
revskill 4y ago
Yeah, i've seen my teammates use this "trick" to get the pull request merged: By introducing more tech debts.
civopsec 4y ago
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!
bentlegen 4y ago
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 4y ago
  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 4y ago
    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.
  - moring 4y ago
    I don't think there is anything wrong with this. You documented the assumptions made when you wrote it, so years later you know them and can say with confidence that you made the right choice. Much less guesswork. Worst thing was that you were a little rude to yourself.
- allenu 4y ago
  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.
ranting-moth 4y ago
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 :)
digitalsushi 4y ago
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.
jdoss 4y ago
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 4y ago
So no one is allowed to have ideas about activities to do unless they have the time to fully implement the idea? Seems odd.
giantg2 4y ago
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 4y ago
  [deleted]
smcleod 4y ago
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.
faizshah 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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.
  - superdug 4y ago
    There are a lot of approaches to this. The way I'd approach something like this, is to find something fairly trivial and just do it. Then ask what you should do with it. I've always found starting a conversation about untracked, but completed useful, change and how to get it done "the right way". See where the conversation goes from there.
alphabettsy 4y ago
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.
walrus01 4y ago
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.
gw98 4y ago
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.
- TurboHaskal 4y ago
  A common issue of having a majority of "feature oriented" engineers on your team is that they block any effort to improve the existing codebase, so while you're cranking features out, the code slowly rots and technical debt creeps in. The counterpart of this is having a majority of "perfection oriented" engineers, in which you have top notch processes and code, but with endless yak shaving and little product work being done :)
angarg12 4y ago
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.
Wronnay 4y ago
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 4y ago
  If it's not ugly you probably should have been faster to market.
cmdrk 4y ago
"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.
- coffeebeqn 4y ago
  I mean it’s usually not something that sees a lot of change. Do you really need to go fix it if it’s been fine for 2years? If something isn’t changing often and thus not looked at often, I’d argue that maybe that effort is best spent on more core parts of the system. Yeah it’s a bit sad that the logging service isn’t running at max capacity but no one really cares. It’s fine
jimbobimbo 4y ago
"We'll fix it later" == "we shipped it like this" couple of months later.
drblast 4y ago
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.
throwaway821909 4y ago
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.
ddoolin 4y ago
Using an absolute like "never" is surely a good way to generate conversation. That said, it's probably more likely you won't go back and fix it, but I have plenty of recent examples where I have committed myself to going back and refactoring things which have been and would likely continue to work for some time, if not "indefinitely" (read: for the life of usage). Depending on what it is, sometimes the mental burden of working in a system full of corner-cutting decisions is worse than the burden of rewriting it. Or, perhaps, I get a large hit of dopamine from refactoring poorly-thought-out systems.
dboreham 4y ago
Comment on the PR that the author must file a bug detailing what has to be fixed later. Only works if you employ processes and practices that ensure bugs get appropriately reviewed and assigned and not lost to /dev/null
curioussavage 4y ago
I dislike this attitude, as far as I'm concerned it just helps perpetuate the environments that don't allow engineers to actually fix things. It's related to the mindset I've seen that prototyping is a waste of time. Out of fear that you get trapped with it. Instead there is this expectation that you just design something close to perfection without any prior attempts.
ChrisMarshallNY 4y ago
Reminds me of Windows deliberately recreating bugs in their software, because applications had been developed that relied on the buggy implementation. I'm really big on testing, and fixing bugs as close to their point of creation as possible. I first read about that, over a quarter-century ago[0]. “plus ça change, plus c'est la même chose “ –Jean-Baptiste Alphonse Karr [0] https://stevemcconnell.com/articles/software-quality-at-top-speed/ https://stevemcconnell.com/articles/software-quality-at-top-... (He's never gotten around to fixing his broken images on that page).
rvr_ 4y ago
Pointing out that the solution is not perfect is fine. It helps future maintainers, even if self. The worst offenders don't even realize the badness of their implementations, intriguing further adventurers of their code's true intentions.
whateveracct 4y ago
I fix stuff in my old code all the time. Personal projects. I don't care at work enough to (and they don't either).
bamboozled 4y ago
Generally I see people never fix "it" later, but often improve the systems which contains "it", there for replacing crappy thing with something a bit better. I'm pretty cynical about coding but the article seems overly cynical to me. I guess that's why the blog is called "useless dev blog" :)
karmakaze 4y ago
> “That’s a hacky way of doing this, but I don’t have time today to come up with a better implementation”. > It got me thinking about when this “hack” might be fixed. I could recall many times when I, or my colleagues, shipped code that we were not completely happy with (from a maintainability / quality / cleanliness aspect, sub-par functionality, inferior user experience etc.). On the other hand, I could recall far far fewer times where we went back and fixed those things. It really only comes down to understanding. Understanding the implementation's choices of abstractions, the domains that are being handled, and the concepts within those domains that the implementation should really be abstracting. When someone does eventually figure this out piece by piece, that's the time that these things can be cleaned up neatly. In the meantime we can, without deep understanding, sometimes still do mechanical refactoring to simplify the situation. It's okay to not understand this all when you ship a temporary hack to production. It's not IMO okay to accept that it will never get figured out, perhaps by someone else, after you're gone, but we should still try.
superdug 4y ago
So don't? At the very least write an explicit unit test for whatever it is. If someone breaks it, at least it will be on your landmine and not at deploy or worse. If you setup a potential for improvement, protect the functionality and ensure it is successfully the next persons problem, but can situationally identified in the future.
sys_64738 4y ago
If you have time to fix the hack independent of modifying that code for a specific need then you should be asking what else you could be working on. Fix it later implies resource availability which is an alien concept for project managers.
rkagerer 4y ago
Erm... it's called refactoring and TODO's. I go back and revamp all the time in my own codebases when it makes sense.
crystaln 4y ago
Hmm. I haven't coded that much in a while, however I went back and refactored fixme's all the time, whenever it made sense and I had to build something on top of the poorly structured code that would bake in the defect. That said, if you're just writing sloppy code out of laziness, you probably won't ever care enough to fix it.
awinter-py 4y ago
I like how this implies the existence of 'load-bearing todos'. Not the more famous load-bearing bug, where other components are built expecting the bad behavior, but mini implementations of the needed behavior elsewhere in the system. If the todo had been done, those mini imps (probably) wouldn't exist. But now that they do, completing the todo is less necessary / actively harmful.
klntsky 4y ago
Managing TODOs is quite straightforward: - Have a development plan with lists of features/problems to be released/fixed in each version - Create an issue for each of the TODOs (and link it in the code comments) - Assign all issues to a particular version milestone - Actually follow the development plan If a TODO is not worth fixing, you will find that out during the project budget evaluation stage before you start working on issues. Although your client may decide not to address the TODO, it will not bother you anymore, because the decision will be on them.
visarga 4y ago
Depends on what kind of work it is - if it's experimental, one time exploration, it's ok to be hacky. If it's a product intended for release and has a long life or intensive compute usage, then it's better to spend the time to make it right. Don't do premature optimisation!
hbrn 4y ago
Here's a simple solution: change your comments (and your mindset) from vague "will fix it later" to a more specific "fix once <trigger condition> occurs". Ideally trigger condition is tied to automated alerts & metrics, but that's not strictly necessary. You'll realize that most of the time trigger condition will not occur in the foreseeable future, or you don't even know what trigger condition is. Latter usually means you're planning to optimize because you want to, not because there's any business value in it. Stop thinking that it needs fixing because there's room for fixing. Businesses are all about tradeoffs, not perfectionism. E.g. instead of "optimize this query in the future" write "optimize this query when we have customers with 1000+ orders", or "optimize this query when response time goes above 500ms", or even "optimize this query when N+ customers complain".
- hashhar 4y ago
  One other thing which I find very useful is to write tests which will start failing once the <trigger condition> changes. For example if today the database version I'm testing against disallows some query shape I can: - write a test that verifies the failure - add a todo comment in code linking to the test to fix the code when test fails Then eventually the test will start failing, you can fix the code and the test and profit.
  - shapefrog 4y ago
    Maybe even put a version test into the tests?
    - hashhar 4y ago
      Good point. But that works only if the version number is the thing you want to test. And also it's possible that newer versions include the bug or some even newer version introduces a regression re-introducing the bug. I'm a believer of user-facing testing - i.e. test things like how a user would operate them. So in the context of building a federated query engine our users won't care what version of Postgres they are connecting to - they will care however that the query they wrote doesn't work - doesn't matter what Postgres version.
ochronus 4y ago
I think neither extreme is right. Tech debt can be a deliberate tradeoff decision. I also understand that in reality, unless managed, tech debt is rarely considered by non-tech people. I've written about how to reason about technical debt: https://leadership.garden/tips-on-prioritizing-tech-debt/ https://leadership.garden/tips-on-prioritizing-tech-debt/
conradfr 4y ago
If your code is sufficiently encapsulated in a way that it's easily deletable and therefore easily replaceable it's perfectly fine to mark it as "fix later". Now, the two examples in the article, not doing data validation server side and starting with Mongodb are not "fix me later" anyway, they're professional mistakes.
tgsovlerkhgsel 4y ago
"either fix it now, or be OK with it never being fixed" - this is in fact the decision that is being made, but saying "later" allows everyone to pretend that it isn't, and do what's actually the right thing (accept "good enough" as good enough) instead of letting perfectionism demand that a perfect solution must take priority over everything else.
WeylandYutani 4y ago
Videogames are a good example. Ship it broken (knowingly testers actually catch all the bugs but the suits upstairs don't give a fuck). If the game sells you'll keep a few sad sack developers working on patches for a few months but otherwise move on to the next HYPE PRODUCT cycle.
meta-level 4y ago
There is one more reason why it's unlikely you fix the hack in the future: unconsciously you feel like / 'admit' you can't do it now, otherwise you would. The obstacle might be the lack of a clear picture of how to proceed, a bad association with the topic or anything else that keeps you from doing it now. So committing a hack can be seen as a symptom of having a reason not to do it now - this reason very likely will still apply `tomorrow()`.
einpoklum 4y ago
This has a lot of truth in life in general, not just in software. We spend so much of it expecting to fix certain things in our relationships, our physical environment, our society - later. But then you grow older, and you realize you'll have a lot less "later"'s available for doing anything than you may have imagined.
alexeiz 4y ago
There should be an intensive to fix hacks. If you approve a PR with a hack there is no intensive to fix it later. Why? The code is already in. But if you don't approve it, block it, until the hack gets fixed, then there is no choice for the author of the hack. Either he fixes it, or his code doesn't get in.
richardjennings 4y ago
Broken gets fixed; Shoddy lasts forever.
pflenker 4y ago
We tend to overestimate our Future Selves: They will have more time, they will be less tired and more motivated and generally be a better version of our current selves. This is why we trust them to implement the New Year Resolutions we've come up with. However, the opposite is true - and the article touches some aspects of this. We're under similar constraints, and additionally, we have forgotten a lot of what we had in mind while writing the code, having to re-learn it before we start working on the fix. What makes things better (besides "fixing it now", of course) is being nice to our Future Self and leaving them with enough context to get started again on the issue should they find the time to do it. This also applies to future co-workers, of course. The opposite is also true: We tend to underestimate the abilities of previous authors of a specific piece of code (sometimes including ourselves) because we do not see the constraints they have been under while producing it.
nailer 4y ago
What? $ git log | grep TODO Fix warning from missing 'alt' on QR code icon, TODO is done TODOs are done Handle TODO Remove old YC TODO Dynamically list NFTs per TODO TODO is now done
frognumber 4y ago
1. I write code in passes and fix things. 2. In most cases, things which never get fixed are good enough "for now" 3. The fixme comment generally means I maintain the flexibility of the planned design, without the complexity/implementation cost. I won't make changes which break a planned fixme. 4. The most common time to fix things is when I need that flexibility. A good example is if I'm planning to make something modular and pluggable. The fixme means I never tie other code to the specific current implementation, even if there's only one. On the other hand, I don't build out the module loader until I actually need it. 90% of the benefit of modules for 10% of the cost.
cauliflower99 4y ago
This is the main disadvantage of remote work IMO. All those little things you think of while writing a solution gets lost in the "I'll do that later" sphere. In comparison, in-person programming in a team provides no excuse. Even if we say we'll do it later, it's not on one person to remember it. The thought gets thrown in the air and caught by someone else on the team. When I'm working alone, the thought gets thrown up but unless I catch it (which I never do), it floats away.
- aidenn0 4y ago
  I always think about teams as on a sliding scale from "can rely on informal communication" to "cannot rely on informal communication" A team of 3 people all in the same office can rely entirely on informal communication. A team of 1000 people distributed throughout the world cannot at all.
solidninja 4y ago
I find it very strange that most of the comments are about how this is okay. I don't think it is, because it prevents software evolution and impedes maintenance. My comment mostly goes to the "hacky" way of implementing something rather than a missing feature/missed performance target. That may indeed never come - though if you have a classic N+1 select problem that is fine now, it's probably good to tag it in the comments, you'd be surprised how quickly it will come. However I have been burned a number of times by a so-called "quick fix" that looks like a bad idea in code review and then later prevents the evolution of the system in some way. Code that is "hacky" usually leaks abstractions, doesn't compose with anything else and only benefits the author at the time it's written as a "quick win". Plus the original author knew enough to call it a "hack" but did not explain why they could not do it properly - a person that consistently does this is not a person you can trust on your team. It is probably up for debate what the balance is (think time value of money but for technical debt), but in the industry it is clearly the wrong side of the scale, and this is a major drag on productivity.
Shorel 4y ago
Really? I am fixing it now.
deterministic 4y ago
Maintain a prioritised list of things to do and always work on #1 priority. In other words, don’t fix the TODO’s if it is not #1 priority. It’s that simple really.

250 points by kiyanwang 4y ago

>Compare this, written and published post, to the list full of “blog post ideas” that never materialized I feel called out...

Scarblac 4y ago
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.
- Jorengarenar 4y ago
  Well, in my humble opinion, you got the order wrong then. You need to start from the idea, the "how" comes later.
  - Scarblac 4y ago
    Yeah, of course, I know. But thinking of good ideas is hard and working on the "how" somehow feels productive, so sometimes I fall into the trap.

lamontcg 4y ago

Counterpoint: it may be a complete waste of time to "fix it right" and the business may be able to sail on for the next 10 years without ever fixing it, and that may be absolutely fine. The perfect code will never ship.

voxelghost 4y ago

One way is to more or less auto-convert (//|#)TODO:, to (//|#)INFO: or (//|#)NOTE: when merging or pushing.

LAC-Tech 4y ago

I have and I will. You don't know me son.

teddyh 4y ago

“There’s nothing more permanent than a temporary solution.”

deleted 4y ago

[deleted]

Helmut10001 4y ago

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 https://github.com/Sieboldianus/TagMaps [2]: https://du.nkel.dev/ https://du.nkel.dev/

mpolichette 4y ago

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 4y ago
> 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 4y ago
  "born in a house with the television always on" That's a Talking Heads lyric and not a point of fact.
- hamburglar 4y ago
  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 4y ago
    > 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"

DerekL 4y ago

Title has a typo: it's missing “will never”.

dang 4y ago
Fixed now. Thanks!
- philipwhiuk 4y ago
  70 minutes later. Any longer and it would never have been fixed ;)
  - dang 4y ago
    Ah drat - clearly I should have posted "we'll fix it in a bit". Oh well!

jasonlotito 4y ago

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 4y ago
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.
- sdiupIGPWEfh 4y ago
  My experience matches yours, and I wanted to call that out with more than just an up-vote. The ticketing system is where rework goes to die. In an engineer-led environment without a project management class calling the shots, maybe I'd feel different, but whoever is ordering the backlog is always going to prioritize features and fires, because that's what drives their own career advancement.

mjr00 4y ago

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.

davidmurdoch 4y ago
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 4y ago
  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.
quonn 4y ago
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 4y ago
  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.

glitchc 4y ago

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.

revskill 4y ago

Yeah, i've seen my teammates use this "trick" to get the pull request merged: By introducing more tech debts.

civopsec 4y ago

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!

bentlegen 4y ago

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 4y ago
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 4y ago
  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.
- moring 4y ago
  I don't think there is anything wrong with this. You documented the assumptions made when you wrote it, so years later you know them and can say with confidence that you made the right choice. Much less guesswork. Worst thing was that you were a little rude to yourself.
allenu 4y ago
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.

ranting-moth 4y ago

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 :)

digitalsushi 4y ago

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.

jdoss 4y ago

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 4y ago

So no one is allowed to have ideas about activities to do unless they have the time to fully implement the idea? Seems odd.

giantg2 4y ago

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 4y ago
[deleted]

smcleod 4y ago

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.

faizshah 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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.
- superdug 4y ago
  There are a lot of approaches to this. The way I'd approach something like this, is to find something fairly trivial and just do it. Then ask what you should do with it. I've always found starting a conversation about untracked, but completed useful, change and how to get it done "the right way". See where the conversation goes from there.

alphabettsy 4y ago

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.

walrus01 4y ago

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.

gw98 4y ago

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.

TurboHaskal 4y ago
A common issue of having a majority of "feature oriented" engineers on your team is that they block any effort to improve the existing codebase, so while you're cranking features out, the code slowly rots and technical debt creeps in. The counterpart of this is having a majority of "perfection oriented" engineers, in which you have top notch processes and code, but with endless yak shaving and little product work being done :)

angarg12 4y ago

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.

Wronnay 4y ago

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 4y ago
If it's not ugly you probably should have been faster to market.

cmdrk 4y ago

"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.

coffeebeqn 4y ago
I mean it’s usually not something that sees a lot of change. Do you really need to go fix it if it’s been fine for 2years? If something isn’t changing often and thus not looked at often, I’d argue that maybe that effort is best spent on more core parts of the system. Yeah it’s a bit sad that the logging service isn’t running at max capacity but no one really cares. It’s fine

jimbobimbo 4y ago

"We'll fix it later" == "we shipped it like this" couple of months later.

drblast 4y ago

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.

throwaway821909 4y ago

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.

ddoolin 4y ago

Using an absolute like "never" is surely a good way to generate conversation. That said, it's probably more likely you won't go back and fix it, but I have plenty of recent examples where I have committed myself to going back and refactoring things which have been and would likely continue to work for some time, if not "indefinitely" (read: for the life of usage). Depending on what it is, sometimes the mental burden of working in a system full of corner-cutting decisions is worse than the burden of rewriting it. Or, perhaps, I get a large hit of dopamine from refactoring poorly-thought-out systems.

dboreham 4y ago

Comment on the PR that the author must file a bug detailing what has to be fixed later. Only works if you employ processes and practices that ensure bugs get appropriately reviewed and assigned and not lost to /dev/null

curioussavage 4y ago

I dislike this attitude, as far as I'm concerned it just helps perpetuate the environments that don't allow engineers to actually fix things. It's related to the mindset I've seen that prototyping is a waste of time. Out of fear that you get trapped with it. Instead there is this expectation that you just design something close to perfection without any prior attempts.

ChrisMarshallNY 4y ago

Reminds me of Windows deliberately recreating bugs in their software, because applications had been developed that relied on the buggy implementation. I'm really big on testing, and fixing bugs as close to their point of creation as possible. I first read about that, over a quarter-century ago[0]. “plus ça change, plus c'est la même chose “ –Jean-Baptiste Alphonse Karr [0] https://stevemcconnell.com/articles/software-quality-at-top-speed/ https://stevemcconnell.com/articles/software-quality-at-top-... (He's never gotten around to fixing his broken images on that page).

rvr_ 4y ago

Pointing out that the solution is not perfect is fine. It helps future maintainers, even if self. The worst offenders don't even realize the badness of their implementations, intriguing further adventurers of their code's true intentions.

whateveracct 4y ago

I fix stuff in my old code all the time. Personal projects. I don't care at work enough to (and they don't either).

bamboozled 4y ago

Generally I see people never fix "it" later, but often improve the systems which contains "it", there for replacing crappy thing with something a bit better. I'm pretty cynical about coding but the article seems overly cynical to me. I guess that's why the blog is called "useless dev blog" :)

karmakaze 4y ago

> “That’s a hacky way of doing this, but I don’t have time today to come up with a better implementation”. > It got me thinking about when this “hack” might be fixed. I could recall many times when I, or my colleagues, shipped code that we were not completely happy with (from a maintainability / quality / cleanliness aspect, sub-par functionality, inferior user experience etc.). On the other hand, I could recall far far fewer times where we went back and fixed those things. It really only comes down to understanding. Understanding the implementation's choices of abstractions, the domains that are being handled, and the concepts within those domains that the implementation should really be abstracting. When someone does eventually figure this out piece by piece, that's the time that these things can be cleaned up neatly. In the meantime we can, without deep understanding, sometimes still do mechanical refactoring to simplify the situation. It's okay to not understand this all when you ship a temporary hack to production. It's not IMO okay to accept that it will never get figured out, perhaps by someone else, after you're gone, but we should still try.

superdug 4y ago

So don't? At the very least write an explicit unit test for whatever it is. If someone breaks it, at least it will be on your landmine and not at deploy or worse. If you setup a potential for improvement, protect the functionality and ensure it is successfully the next persons problem, but can situationally identified in the future.

sys_64738 4y ago

If you have time to fix the hack independent of modifying that code for a specific need then you should be asking what else you could be working on. Fix it later implies resource availability which is an alien concept for project managers.

rkagerer 4y ago

Erm... it's called refactoring and TODO's. I go back and revamp all the time in my own codebases when it makes sense.

crystaln 4y ago

Hmm. I haven't coded that much in a while, however I went back and refactored fixme's all the time, whenever it made sense and I had to build something on top of the poorly structured code that would bake in the defect. That said, if you're just writing sloppy code out of laziness, you probably won't ever care enough to fix it.

awinter-py 4y ago

I like how this implies the existence of 'load-bearing todos'. Not the more famous load-bearing bug, where other components are built expecting the bad behavior, but mini implementations of the needed behavior elsewhere in the system. If the todo had been done, those mini imps (probably) wouldn't exist. But now that they do, completing the todo is less necessary / actively harmful.

klntsky 4y ago

Managing TODOs is quite straightforward: - Have a development plan with lists of features/problems to be released/fixed in each version - Create an issue for each of the TODOs (and link it in the code comments) - Assign all issues to a particular version milestone - Actually follow the development plan If a TODO is not worth fixing, you will find that out during the project budget evaluation stage before you start working on issues. Although your client may decide not to address the TODO, it will not bother you anymore, because the decision will be on them.

visarga 4y ago

Depends on what kind of work it is - if it's experimental, one time exploration, it's ok to be hacky. If it's a product intended for release and has a long life or intensive compute usage, then it's better to spend the time to make it right. Don't do premature optimisation!

hbrn 4y ago

Here's a simple solution: change your comments (and your mindset) from vague "will fix it later" to a more specific "fix once <trigger condition> occurs". Ideally trigger condition is tied to automated alerts & metrics, but that's not strictly necessary. You'll realize that most of the time trigger condition will not occur in the foreseeable future, or you don't even know what trigger condition is. Latter usually means you're planning to optimize because you want to, not because there's any business value in it. Stop thinking that it needs fixing because there's room for fixing. Businesses are all about tradeoffs, not perfectionism. E.g. instead of "optimize this query in the future" write "optimize this query when we have customers with 1000+ orders", or "optimize this query when response time goes above 500ms", or even "optimize this query when N+ customers complain".

hashhar 4y ago
One other thing which I find very useful is to write tests which will start failing once the <trigger condition> changes. For example if today the database version I'm testing against disallows some query shape I can: - write a test that verifies the failure - add a todo comment in code linking to the test to fix the code when test fails Then eventually the test will start failing, you can fix the code and the test and profit.
- shapefrog 4y ago
  Maybe even put a version test into the tests?
  - hashhar 4y ago
    Good point. But that works only if the version number is the thing you want to test. And also it's possible that newer versions include the bug or some even newer version introduces a regression re-introducing the bug. I'm a believer of user-facing testing - i.e. test things like how a user would operate them. So in the context of building a federated query engine our users won't care what version of Postgres they are connecting to - they will care however that the query they wrote doesn't work - doesn't matter what Postgres version.

ochronus 4y ago

I think neither extreme is right. Tech debt can be a deliberate tradeoff decision. I also understand that in reality, unless managed, tech debt is rarely considered by non-tech people. I've written about how to reason about technical debt: https://leadership.garden/tips-on-prioritizing-tech-debt/ https://leadership.garden/tips-on-prioritizing-tech-debt/

conradfr 4y ago

If your code is sufficiently encapsulated in a way that it's easily deletable and therefore easily replaceable it's perfectly fine to mark it as "fix later". Now, the two examples in the article, not doing data validation server side and starting with Mongodb are not "fix me later" anyway, they're professional mistakes.

tgsovlerkhgsel 4y ago

"either fix it now, or be OK with it never being fixed" - this is in fact the decision that is being made, but saying "later" allows everyone to pretend that it isn't, and do what's actually the right thing (accept "good enough" as good enough) instead of letting perfectionism demand that a perfect solution must take priority over everything else.

WeylandYutani 4y ago

Videogames are a good example. Ship it broken (knowingly testers actually catch all the bugs but the suits upstairs don't give a fuck). If the game sells you'll keep a few sad sack developers working on patches for a few months but otherwise move on to the next HYPE PRODUCT cycle.

meta-level 4y ago

There is one more reason why it's unlikely you fix the hack in the future: unconsciously you feel like / 'admit' you can't do it now, otherwise you would. The obstacle might be the lack of a clear picture of how to proceed, a bad association with the topic or anything else that keeps you from doing it now. So committing a hack can be seen as a symptom of having a reason not to do it now - this reason very likely will still apply `tomorrow()`.

einpoklum 4y ago

This has a lot of truth in life in general, not just in software. We spend so much of it expecting to fix certain things in our relationships, our physical environment, our society - later. But then you grow older, and you realize you'll have a lot less "later"'s available for doing anything than you may have imagined.

alexeiz 4y ago

There should be an intensive to fix hacks. If you approve a PR with a hack there is no intensive to fix it later. Why? The code is already in. But if you don't approve it, block it, until the hack gets fixed, then there is no choice for the author of the hack. Either he fixes it, or his code doesn't get in.

richardjennings 4y ago

Broken gets fixed; Shoddy lasts forever.

pflenker 4y ago

We tend to overestimate our Future Selves: They will have more time, they will be less tired and more motivated and generally be a better version of our current selves. This is why we trust them to implement the New Year Resolutions we've come up with. However, the opposite is true - and the article touches some aspects of this. We're under similar constraints, and additionally, we have forgotten a lot of what we had in mind while writing the code, having to re-learn it before we start working on the fix. What makes things better (besides "fixing it now", of course) is being nice to our Future Self and leaving them with enough context to get started again on the issue should they find the time to do it. This also applies to future co-workers, of course. The opposite is also true: We tend to underestimate the abilities of previous authors of a specific piece of code (sometimes including ourselves) because we do not see the constraints they have been under while producing it.

nailer 4y ago

What? $ git log | grep TODO Fix warning from missing 'alt' on QR code icon, TODO is done TODOs are done Handle TODO Remove old YC TODO Dynamically list NFTs per TODO TODO is now done

frognumber 4y ago

1. I write code in passes and fix things. 2. In most cases, things which never get fixed are good enough "for now" 3. The fixme comment generally means I maintain the flexibility of the planned design, without the complexity/implementation cost. I won't make changes which break a planned fixme. 4. The most common time to fix things is when I need that flexibility. A good example is if I'm planning to make something modular and pluggable. The fixme means I never tie other code to the specific current implementation, even if there's only one. On the other hand, I don't build out the module loader until I actually need it. 90% of the benefit of modules for 10% of the cost.

cauliflower99 4y ago

This is the main disadvantage of remote work IMO. All those little things you think of while writing a solution gets lost in the "I'll do that later" sphere. In comparison, in-person programming in a team provides no excuse. Even if we say we'll do it later, it's not on one person to remember it. The thought gets thrown in the air and caught by someone else on the team. When I'm working alone, the thought gets thrown up but unless I catch it (which I never do), it floats away.

aidenn0 4y ago
I always think about teams as on a sliding scale from "can rely on informal communication" to "cannot rely on informal communication" A team of 3 people all in the same office can rely entirely on informal communication. A team of 1000 people distributed throughout the world cannot at all.

solidninja 4y ago

I find it very strange that most of the comments are about how this is okay. I don't think it is, because it prevents software evolution and impedes maintenance. My comment mostly goes to the "hacky" way of implementing something rather than a missing feature/missed performance target. That may indeed never come - though if you have a classic N+1 select problem that is fine now, it's probably good to tag it in the comments, you'd be surprised how quickly it will come. However I have been burned a number of times by a so-called "quick fix" that looks like a bad idea in code review and then later prevents the evolution of the system in some way. Code that is "hacky" usually leaks abstractions, doesn't compose with anything else and only benefits the author at the time it's written as a "quick win". Plus the original author knew enough to call it a "hack" but did not explain why they could not do it properly - a person that consistently does this is not a person you can trust on your team. It is probably up for debate what the balance is (think time value of money but for technical debt), but in the industry it is clearly the wrong side of the scale, and this is a major drag on productivity.

Shorel 4y ago

Really? I am fixing it now.

deterministic 4y ago

Maintain a prioritised list of things to do and always work on #1 priority. In other words, don’t fix the TODO’s if it is not #1 priority. It’s that simple really.