Timeline for How can I favor quick (and dirty) over clean (and slow) in practice?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 23, 2023 at 23:47 | comment | added | rooby | @Heinzi At first I thought this answer was a joke, but your comment indicates you actually do follow these rules, so now I'm not sure. I've worked on projects that started out with this kind of mindset and now they are somewhat of a jumbled mess and adding things that should be fairly simple involves either a bunch of refactoring that takes way longer than it should, or continuing to follow this mantra and making the mess messier. You can get away with it for a while but on long term projects you will eventually hit a wall where you have to do major and painful refactoring. | |
| Apr 22, 2022 at 7:31 | audit | First answers | |||
| Apr 22, 2022 at 7:33 | |||||
| Apr 11, 2022 at 15:53 | comment | added | James_pic | I've certainly seen cases other than time-critical emergency hotfixes where these techniques make sense. This is a reasonable approach for any code that only has to barely work, and only do so once. My experience might be atypical, but I've found that this isn't an especially rare situation. If you're writing code to change the dates in your test data, or to reproduce a weird issue, or grab a one-off report to figure out how much of your data has been affected by some bug, it's enough for it to barely work once. | |
| Apr 9, 2022 at 12:14 | comment | added | Heinzi | @RobertHarvey: All very good points, and I actually agree with all of them. Any maybe I should admit that those practices are not really "forbidden" in our team - you're just not allowed to use them without a good reason. Those points you mention are good reasons; "I was lazy", however, is not. | |
| Apr 9, 2022 at 12:13 | comment | added | Robert Harvey | 5. Your code should be easy enough to read so that you don't need comments most of the time. Comments should be reserved for explaining why, not how, and should be used primarily to point out relationships between classes and methods (i.e. architectural considerations). | |
| Apr 9, 2022 at 12:11 | comment | added | Robert Harvey | 4. It depends. If you're in a small local scope, x, count or var are perfectly good names for variables, and if you are writing your code correctly, you should be in a small local scope much of the time. | |
| Apr 9, 2022 at 12:09 | comment | added | Robert Harvey | 3. This is YAGNI, although I'm not sure your example is a great one. In general, message boxes are the most expensive UI element there is, from a user perspective; I try to avoid them whenever possible. | |
| Apr 9, 2022 at 12:07 | comment | added | Robert Harvey | 2. Copy/pasting code and modifying it is absolutely the right thing to do in many cases. DRY can be taken to absurd extremes that waste time, make the code more complex and difficult to read, and do nothing to improve the overall architecture. | |
| Apr 9, 2022 at 12:02 | comment | added | Robert Harvey | 1. But don't attempt to obtain 100% code coverage either. You won't get it. There is a sweet spot for testing; write enough tests to demonstrate that the code works, and no more than that. | |
| Apr 9, 2022 at 11:19 | comment | added | Heinzi | @Gulzar: From personal experience in writing both production-quality and single-use throwaway code: Yes, they do make you faster - initially. As you correctly point out, dirty coding can come back to haunt you much sooner than you'd expect. And, obviously, the long-term cost usually outweighs the short-term gains by a large factor. In fact, the only legitimate use case I see for these techniques would be small, time-critical emergency hotfixes (system is down and customer loses $$$ per hour), but even then I'd try to replace it with a clean solution as soon as possible. | |
| Apr 9, 2022 at 9:58 | comment | added | Gulzar | Does tese really make you faster? Not being able to read my own code, or having to do things several times makes me slower already in the same coding session! Could you maybe give an example of when this can be clearly applied? | |
| Apr 9, 2022 at 9:02 | history | answered | Heinzi | CC BY-SA 4.0 |