Timeline for How can I favor quick (and dirty) over clean (and slow) in practice?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 10, 2022 at 21:57 | history | edited | Sinc | CC BY-SA 4.0 | Insert a paragraph with credit to original designers. |
| Apr 10, 2022 at 21:44 | comment | added | Sinc | Next observation: perfection and completeness are subjective. My architect and I agreed on one fundamental principle: No matter what you think the feature is for, and what you think about how it will be used, you are giving it to 1000 trained monkeys, and they WILL think of, or trip over, several creative ways to use it that you can't dream of. Accept that you can't test for that, keep it operationally as open as possible, and let them be creative. But also accept that since you didn't think of it, the operation may need tweaking to be correct. | |
| Apr 10, 2022 at 21:41 | comment | added | Sinc | @Gulzar the first thing to accept with being quick and dirty is to get past the obsession with perfection. Obsess over basic correctness, but not perfection. I want my fix to work 1) in the case that I'm fixing, 2) obvious similar cases, but not necessarily demonstrably 3) in all cases. Nobody's got time for that, there's the next problem to fix or feature to write. And it's hard to prove completeness. | |
| Apr 10, 2022 at 21:35 | comment | added | Sinc | @Gulzar the two points you claim are contradictory are just two examples of how you avoid perfection. The first is the attitude that test cases are redundant because I know I write perfect code. The second is independent of that - that I don't need to worry too much about the edge cases because they rarely happen. Both assumptions save a lot of time when you just want to get the code done quickly. Savings can be huge with that. My new guy found a one line fix the other day then had to create a 40 line test case to verify old and new functionality. What a waste! | |
| Apr 9, 2022 at 21:24 | comment | added | ciamej | @Gulzar If you want to learn to be quick and dirty don't look for books on that topic, just practice. Take some open source code that you've never seen before; think of some new feature you'd like to add; give yourself a constant amount of time, e.g. 1 hour; and then you go -- do all it takes to implement that feature in one hour. Even if it won't be perfect, and there is going to be a high chance of the software crashing don't mind it, just make it work most of the time. Then, you can take another 1 hour iteration to improve that stuff a bit... | |
| Apr 9, 2022 at 21:20 | comment | added | ciamej | @Gulzar I think you have an obsession about avoiding all errors, while "quick and dirty" is all about making errors ;) maybe not on purpose, but surely by admitting the possibility that you are not sure what you are doing, but still going forward. | |
| Apr 9, 2022 at 21:17 | comment | added | ciamej | @Gulzar "Do you have to understand all of it?" -- the OP clearly stated that that's not the case. See "You got in, figured out the minimum that you needed to to get a fix done, and got out." or "Development of new features was done, as much as practical, by copying whatever bits you needed from the existing base, because you knew that stuff worked, without needing to understand it completely." | |
| Apr 9, 2022 at 9:44 | comment | added | Gulzar | That's really an interesting read, thanks! Still, I would really like to take the pragmatic approach, and don't see how from this. You contradict yourself in the 1st paragraph already- "i know it works..edge cases are not important". Let's leave that. Hpw can you do ANY change in such large code with no order? Do you have to understand all of it? What if you can't? | |
| Apr 9, 2022 at 3:14 | history | answered | Sinc | CC BY-SA 4.0 |