5 ms·
> “code someone else wrote that I’d rather rewrite than understand” I'm not disagreeing, but there is something to be said for writing code that any idiot can
by mabbo 8y ago
> “code someone else wrote that I’d rather rewrite than understand”
I'm not disagreeing, but there is something to be said for writing code that any idiot can understand so that future developers don't even want to rewrite it, and can maintain it.
I've landed in code bases on both ends of the spectrum, and I never asked management to rewrite the well-written ones.
- maxxxxx 8y agoThere is a level of luck involved in producing well written code. Sometimes your assumptions turn out to be correct and sometimes a big requirements change comes and turns your code from simple to super complex.
- MaxBarraclough 8y agoSure, a giant-ball-of-mud codebase might be the result of changing requirements and assumptions, but it could be the result of laziness/unskilled development. There's a skill to writing readable, ideally self-documenting code. If that skill is wanting, even the most stable requirements won't save you from the mud.
- maxxxxx 8y agoCorrect. But don't forget that it can also go the other way. The best code writing skills can be defeated by ever changing requirements. Besides code writing there is a also a skill in being disciplined about requirements changes.
- mixmastamyk 8y ago> could be the result of laziness/unskilled development. Or not being allowed/kept too busy to fix it.
- waterlink 8y agoIt seems like: “rewrite” is in sense of “I don’t even want to understand it, going to just delete it, and implement anew”, VS “refactor” is in sense of “I had to spend quite a while trying to understand this code, and I think it can be improved, so that the next developer doesn’t have to spend this time.”
- MaxBarraclough 8y agoSee also "Chesterton's fence"
- sixstringtheory 8y agoThat is a fantastic tidbit, TIL. This is pretty much what I had in mind to refute the assumption the earlier parent made about rewrites being desired so code doesn't have to be grokked. IME, the tech debt we complained about was in situations where we knew what we had to do to write a new feature, and why it wouldn't work because of the decisions made previously, and the monumental amount of work involved in putting just one more bandaid on that system, instead of just fixing the dang data model.
- ben509 8y agoThat makes me wonder: if I fix something, if I set up Chesterton's fence, how can I make it a bit more obvious why I'm putting that fence there for the benefit of future us?
- MaxBarraclough 8y agoThe usual code-comments/self-documenting code/git commit descriptions, no? If a long-form explanation is justified, wikis are cheap. I see no excuse for leaving the reader to guess at what on Earth you were thinking. Implementing a wacky solution is sometimes a necessary evil. Incomprehensibility isn't.
- gknoy 8y agoAt the risk of sounding snarky, I feel like a block of code comments explaining the naiive approach that was rejected, as well as the particular edge cases that this is handling which the simpler generalized case doesn't handle, would help a lot for that. I realize that as developers we often glaze over the comments (my editor even shows them as low contrast grey), but docstrings and code comments can be tremendously valuable when trying to understand why something needs to do things a particular way.
- omeid2 8y agoIn a wicked way, people who write that kind of code never get credit for it, and often lose leverage of their job. I am not saying that writing convoluted code is good, no, but I can tell, even if based on personal experience, that barely anyone talks about "wow, this is such a straight forward code" or gets promoted for "everyone can understand your code!". It is a weird dynamic that gets worst by having non-technical managers, and the reason why I believe team leaders should be hands-on in software development and involved with code review.
- waterlink 8y agoLet me get this straight: Person A, a programmer, who writes easy-to-understand code, but takes a bit more time to finish their tasks Person B, a programmer, who writes dirty code, but takes much less time to finish their tasks The current non-technical manager will see only one part of the picture and promote Person B. Moreover, Person A might get in trouble, and pressure to “compromise on quality.” Within a short-term, it is understandable. Within a long-term, this is a disaster scenario! So should the “code quality” be part of a performance portfolio of the developer when it gets to promotion time? And how do we get there?
- monocasa 8y agoI've also seen Programmer A writes straightforward code that's easy to change and understand. Programmer B writes convoluted "clever" code that completely falls apart when requirements change, or even just in production because their clever solution didn't account for all of the edge cases. Now Programmer B has to save the day consistently, and therefore is seen as the person saving the company, when the problems were all of Programmer B's construction to begin with.