7 ms·
Code Lifespan
- AlbertCory 4y agoSpot on. And why code reviews are at least 70% a waste of time. (Note that I left 30% for some of them to do some good, occasionally.)
- hot_gril 4y agoCode reviews are useful when the reviewers don't have OCD, which is only about half the time.
- Gigachad 4y agoAll OCD and preferences should be encoded in the linter/formatter or a wiki page. It's obviously a waste of time to argue menial preferences in review.
- hot_gril 4y agoSome of the documented preferences are annoying too, but at least you can adhere to them without going back and forth with a reviewer. What builds friendships is when you review each other's code in a way that ignores the parts of the style guide you both consider silly.
- AlbertCory 4y agoThe xkcd cartoon hits on an orthogonal dimension, almost universally ignored, which is why I liked it: It's an economic endeavor, not an artistic one. I've been in some choruses, and it's really worth it to make every single thing as good as you can possibly make it. The audience for the concert appreciates the totality of what you do. A coding project is not art like that. It's not worth making most things perfect, and moreover, you can't tell now which ones are going to be worth it. Every hour you spend on polishing something that's going to be thrown away in two years is an hour you can't be doing something more valuable. The Net Present Value of extra work five years from now is almost zero.
- hot_gril 4y agoWell it's the same dimension, obsessive code review wastes time and money.
- Gigachad 4y agoI've generally found pair programming to be more useful than code reviews. It's too hard to drop in at the end of someones weeks of work and try to meaningfully review it. And a lot of suggestions you might have would have been useful at the start of the work but aren't worth going back to fix. If you actually sit along and see the whole process you can actually understand the whole piece of work as well as give suggestions when they are useful and much cheaper to action.
- rqtwteye 4y agoAt least reviews should be pair reviews where you talk to the author and can ask questions.
- mattbessey 4y ago> at the end of someones weeks of work That sounds like more of a criticism of large PRs and long feedback cycles than of code review itself.
- dcow 4y agoThe goal of a code review should be to establish shared ownership. If that is valuable to your engineering org or team, then code reviews are valuable. Often teams don't have the time or discipline to treat reviews that way, in which case they are not valuable (or negatively valuable because they waste engineering bandwidth). A practice that I've seen work well is for the engineer writing the code or the team in general to have enough situational awareness to realize when something really would benefit from having immediate shared ownership vs when something doesn't and the responsibility falling on the code author or otherwise team to determine which pieces of work should be more thoroughly reviewed.
- AnimalMuppet 4y agoOne of the goals of a code review should be to establish shared ownership (or at least shared-semi-competence). But code reviews have at least one other way of contributing value. They help find (moderately) obvious bugs, unsafe code, and unclear code. There is value in keeping blatant stupidity out of your codebase.
- dcow 4y agoThose are 2nd order benefits derived from establishing shared ownership.
- AnimalMuppet 4y agoThat statement is false. If I call your code, I don't have to share ownership of your code to benefit from your code not having a bug in it.
- dcow 4y agoThat’s not what I said. I said you get the second order benefits by establishing shared ownership. Of course the qualities of the code are conferred to callers… that’s obvious.
- deleted 4y ago[deleted]
- kuczmama 4y agoSeems about right.
- markyc 4y agoand javascript was born
- hot_gril 4y agoPeople where I work tend to act like their code is going to never be changed later. Like yo, I could rewrite my thing 5 times in the amount of time it took you to build the "generalized" solution that'll probably break anyway. My entire job the past 4 years has been keeping some overengineered thing on life support until its author leaves the team and I nuke/rewrite it, and one of my teammates is like me.
- mikojan 4y agoWhere I work you decide whether to produce over-engineered or under-engineered crap prior to writing it and people cannot waste time on a rewrite just because someone left.
- hot_gril 4y agoYeah I've got a lot of luxury here. Used to be in startups where the whole thing can be FUBAR from a mistake like that.
- simmerup 4y agoWhere I work everyone decides to rewrite everything they inherit and nothing ever gets delivered because the business loses patience and reassigns priorities as the rewrite drags on.
- einpoklum 4y ago> I could rewrite my thing 5 times But in 20 years... 1. It is many people's thing, not your thing. 2. It is inter-dependent with code you can't rewrite 5 times 3. You're probably no longer there anyway. So I'll have the generalized solution, thank you. Of course, it's even better if you can use an already well-established FOSS solution, since that's likely to see improvements over time which may be applicable to your code.
- hot_gril 4y agoIn 20 years, it's gone, the business requirements are unpredictably different, probably the language I wrote it in is gone too, maybe the entire company as well. I'm writing application code, not a kernel or something, but even kernel pieces have API boundaries and can be replaced. An API can live 20 years, so I take that far more seriously.
- seadan83 4y agoI feel like some of the earliest advice and an early learning principle was: - design for reasonable extensions in the future. Is your design modular, will it be easy to add features? Did you solve problems in a generic way that could be re-used for other other solutions? For example, instead of doing a graph traversal, did you solve the problem by first writing a graph traversal library? I don't think it's quite as widespread, I would posit that this has changed to: - (1) YAGNI, build the simplest solution you can for the problem at hand. That will make it as easy as possible to change when future requirements are presented. (2) Design your code to be replaced, not extended. Design your modules in a way that someone can rewrite one without having to rewrite the whole system. Points (1) & (2) really contradicts the generalized solution approach. The generalized solution tends to be very abstract, hard to understand, and because there are layers - not very modular (which makes it hard to re-write)
- Buffout 4y ago"generalized" means the most simple code you can come up with. This simple code is then used thousands times from very different programs, and it never changes.
- seadan83 4y agoSee XKCD comic : ) I would disagree that "generalized" equates to simple. Generalized means generic and usually abstract. - https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... - https://blog.codinghorror.com/rule-of-three/ https://blog.codinghorror.com/rule-of-three/ "It is three times as difficult to build reusable components as single use components" I think implicit in the point, most code does not go on to be used thousands of time (let alone dozens or even more than once). Even if some code is used more than once, making it the same and shared has significant costs as well.
- Buffout 4y agoNever said it is easy to build simple reusable code. Code itself must be simple but process behind devising it may not be. If the code is not simple it is more prone to error.
- Willish42 4y agoGenerally, the more (over-)engineered something is, the more of a pain it is to reuse/maintain/etc. Simple code is more likely to be grok'd easily by readers, and therefore reused as many places as possible. Working in an organization where there's a lot of overengineering going on constantly and it definitely feels like a significant portion is wasted effort for the time horizon such projects survive for. Randall Monroe observations for this kind of stuff are always really spot on. I wonder what his creative process is like. I should probably read XKCD more often...
- Pasorrijer 4y agoI mean, the thing about a quick hack job is the person building the code has a very well defined problem and knows exactly what will fix it. And so that's almost a perfect requirements to solution match.
- csours 4y agoLooking at some 20 year old code and continuously telling myself "They just made it work" whenever I ask why would anyone do this.
- daemonhunter 4y agoIt’s accurate. Q&D stuff seems to have long lifespans.
- feoren 4y agoI see this kind of opinion a lot, and it's clearly resonating in the comments. I'm beginning to think most people are just very bad at writing reusable code. Despite all the negativity, it is actually possible to write highly-reusable code that is clean, understandable, and not "over-engineered". Why have you all given up on that?
- thfuran 4y agoBut the comic isn't suggesting that it can't be done, only that it's often hard to guess ahead of time when the effort is warranted.
- Gigachad 4y agoThe team manager at work likes to bring up the list of "time investments which we will benefit from later" which we never benefited from later. It's a good point that usually its better to wait until the benefits are obvious rather than predicting at some point there will be some benefit later.
- HankB99 4y agoMy general strategy - usually applied on a much smaller scale - was the first time I needed to do something similar (or the same) I'd copy the code. The second time, I'd consider abstracting it. By that time I had three applications and could better identify what was common and what was specific to a particular usage. I wonder if something like that can be applied to larger libraries.
- personalidea 4y agoThat is what I tend to do as well. Heard it being called AHA programming. Avoid hasty abstractions.
- fasterik 4y ago> it is actually possible to write highly-reusable code that is clean, understandable, and not "over-engineered" This is true for systems where you already have working code and you have multiple concrete examples of code that would benefit from refactoring or rewriting a reusable module. I think the skepticism is more toward the idea that you should design for reuse up front before you have working code. There are two failure modes. One is that you spend time making something reusable that you only end up using in one place. The other is that you bake assumptions into the code that later turn out to be false. In both cases, the resources spent on reusability could have a net negative impact on the project.
- Nevermark 4y ago> It took some extra work [... ==> ...] ensure code is never reused. Simplifies to: Code is never reused (99.99% probability) > Let's not overthink it [... ==> ...] code lives forever. Simplifies to: Reused code is always underwhelming (99.99% probability) Solution? This is the optimum! Tuning 0.01% of situations isn't a good use of time. Stop worrying and learn to love the spaghetti!
- travisjungroth 4y agoIf these are independent, the probability that code is reused and not underwhelming is 0.000001%. Sounds about right.
- deleted 4y ago[deleted]
- jedberg 4y agoI hacked together a deployment system in Perl when I first started at reddit. It was the first deployment system reddit had (previously they would just scp the files to the servers by hand). I heard it wasn't retired until 10 years after I wrote it (which was about 6.5 years after I left).
- rqtwteye 4y agoA lot of the people who complain about the bad code of legacy systems don't understand that their code has a good chance to be legacy in 20 years. Makes me wonder how well the "microservice/k8s/many third party packages" apps will age. I suspect not well. I am always shocked when I learn the some code I wrote as throwaway-tp-be-done-right-later 10 years ago is still in use.
- orangeoxidation 4y ago> I am always shocked when I learn the some code I wrote as throwaway-tp-be-done-right-later 10 years ago is still in use. That's because your "quick throwaway" code solves a real problem. It is useful, it works, it is very likely easy to understand. In short: It's good code. (It might not be "elegant" or "clever" or even "neat". Those things are overrated.)
- MathMonkeyMan 4y agoI hadn't thought of it this way. Good perspective. I'll inject some cynicism, though: > It is useful, it works, it is very likely easy to understand. It probably mostly solves the intended problem, and might be so close to coming apart that nobody dares improve it.
- MagicMoonlight 4y agoAll those stupid front end libraries will be the new mainframe. >Guys I’ve been stuck with this application that says its a web app doesn’t render in the browser engine. It has its own version of a browser engine that’s from thirty years ago and it needs 200 dependencies from a repository that doesn’t exist anymore. How am I supposed to maintain this?
- shreddit 4y agoThere is a german saying “Nichts hält länger als ein Provisorium” which roughly translates into “Nothing lasts longer than a temporary solution”…
- louwrentius 4y agoSounds like a variant of "Nothing is as permanent as a temporary solution". Or if I'm allowed to say it in Dutch: "Niets is zo permanent als een tijdelijke oplossing."
- scotty79 4y ago"Najtrwalszą rzeczą jest prowizorka." The most durable thing is makeshift.
- eps 4y agoAs an old saying goes +---------------------------------+ | There is nothing more permanent | | than something temporary | +---------------------------------+
- vanjajaja1 4y ago"An old arabic proverb: that which happens once, will never happen again. that which happens twice, will surely happen a third time."
- gregwebs 4y agoThis may ring true in part due to survivorship bias. The quick hacky approach can potentially produce a lot more code than the perfected implementation. If both are actually equally likely to be used in the future there are a lot more survivors from the quick hacky stuff.
- psion 4y agoI wrote an amazing feature for a client's website. Saw how awesome it was going to be, wrote it so we could use it on other websites. Even pitched it to my boss on how to pitch it to another client. That code shipped and was never used again.
- freddref 4y agoIs your code easily deleted? That would be better than - is your code easily modified? Change is hard, starting again is more fun.
- taeric 4y agoI wish I could convince my org that the easier to delete items are far preferable to the over engineered ones. It is fun, as we "know" that "build one to throw away" is wise advice. We still find every way possible to make it hard to throw what we are working on away.
- MattPalmer1086 4y agoHah. For a startup I wrote some code using interfaces and some (what I though to be) reasonable abstractions to future proof us to an extent. Some of it remained quite low level where appropriate. All the other dev leaders hated it. They said it was too complex and they couldn't iterate on it quickly enough. It took one of them 2 hours to change a fundamental bit of it! They then (after I left that position to work on the cryptography) proceeded to rewrite the entire thing using domain oriented design. It was a beautiful set of interfaces. It was about 100 times less efficient (running on mobile phones). It took them 6 months to rewrite it. I figure that everyone just has their preferred style. The right amount of abstraction is whatever you wrote!
- simmerup 4y agoIn my opinion if you have something that you can afford to spend tons of time over engineering before it’s delivered, then it’s not important to the business. If you’re being screamed at to deliver asap and having to take shortcuts, that’s when your short term MVP proof of concept gets embedded unless you have someone really good watching over you
- renewiltord 4y agoCode is liability, guys. Functionality is value. And total value is the integral of the instantaneous value, and total cost is the integral of the instantaneous cost. Engineers frequently have trouble with this. They place the code on the wrong side of the balance sheet. They place it on the assets side. It's on the liabilities side.
- tanseydavid 4y ago"Use before reuse" is probably one of the best guiding principles I have heard.
- deleted 4y ago[deleted]