Timeline for How to deal with misconceptions about "premature optimization is the root of all evil"?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 26, 2016 at 6:20 | comment | added | Doc Brown | @cmaster: IMHO discussing this in this broad generality does not lead us anywhere. There is not "the one and only correct way" to find a good architecture. And I did not write you should ignore performance considerations when picking or building an architecture, quite the opposite - read my comments again. And as sidenote: the OP had a quite smaller scenario in mind, what you can see if you read his comments to the other answers. | |
| Apr 25, 2016 at 9:14 | comment | added | cmaster - reinstate monica | I second @sdenham: There is no premature optimization while designing the fundamental architecture. If you analyse the problem and ignore all performance considerations, your design will be slow, and it will be impossible to fix it without rewriting the majority of code. You really only have one shot to get your design right, and if you don't, you waste a lot of implementation effort. Later on in the process, when you are implementing the design, premature optimization exists and needs to be avoided, but the gains/losses of a slow/fast design are so huge that they must not be ignored. | |
| Apr 15, 2016 at 6:13 | history | edited | Doc Brown | CC BY-SA 3.0 | added 108 characters in body |
| Apr 13, 2016 at 13:56 | comment | added | Doc Brown | ... moreover, on an architectural level, things are not black-and-white - you can often find compromises. For example, lets assume we picked a programming language like Python, and now find out it is too slow for a certain task, but using a C compiler would help. Sure, you cannot easily port the Python program to C afterwards when you have already written 100K LOC, but often it is possible to implement that one task in C which bothers you. Even in that situation, you start with the Python implementation first, try & measure, and then optimize afterwards, not the other way round. | |
| Apr 13, 2016 at 13:36 | comment | added | Doc Brown | @sdenham: at the level of architectural design, you need to make estimations for making the right performance decisions, exactly what I wrote in my question. If you are unsure, it will be a good idea to test an architecture by implementing a prototype or spike before picking an unnecessary complicated solution. Moreover, the question is not IMHO aiming at that level. | |
| Apr 13, 2016 at 12:42 | comment | added | sdenham | This is good advice for programming-in-the-small, but ignoring performance questions at the level of architectural design can lead a team down a long dead-end, because it might get a lot done before it is forced to confront the problem, and there is no guarantee that much of that work is reusable when the problem is architectural (I have seen it kill a product.) I know you have an exception in your answer, but to know whether it applies you still have to ask the question, and even asking the question is apparently anathema to errantlinguist's co-workers. | |
| Apr 12, 2016 at 21:07 | history | edited | Doc Brown | CC BY-SA 3.0 | added 295 characters in body |
| Apr 12, 2016 at 21:02 | history | edited | Doc Brown | CC BY-SA 3.0 | added 295 characters in body |
| Apr 12, 2016 at 20:56 | vote | accept | errantlinguist | ||
| Apr 12, 2016 at 20:54 | comment | added | errantlinguist | Oops, yeah. I meant that the explanation of what to focus on in a discussion really helped me. I'll accept this answer then, anyway, since the comments explain it. | |
| Apr 12, 2016 at 20:52 | comment | added | Doc Brown | @errantlinguist: if I make what into an answer? Do you mean I should add something from my comments into my answer which is missing there? Oh, and I bet chances are not bad your question will be reopened again. | |
| Apr 12, 2016 at 20:48 | comment | added | errantlinguist | @DocBrown: Thanks for the advice. If you make that into an answer, I'll try to accept it before this question gets closed. | |
| Apr 12, 2016 at 20:22 | comment | added | jl6 | @errantlinguist: I'm not sure how you reach that conclusion. Doc Brown's answer seems perfectly clear: you cut through these unproductive arguments that you are having with your colleagues by sticking to factual statements about what is and isn't acceptable performance. | |
| Apr 12, 2016 at 20:07 | comment | added | Doc Brown | @errantlinguist: not bury it - put those aspects into focus, when it is correct that those aspects should be in focus, and do not use performance as an argument when you cannot prove it that it makes an important difference for the end user. | |
| Apr 12, 2016 at 19:25 | comment | added | errantlinguist | So, combined with my own experiences regarding avoiding the word "optimization", it seems that basically the way to deal with these people is simply to never mention it and to bury it inside other topics like "more maintainable architecture", "smaller codebase", etc.? | |
| Apr 12, 2016 at 19:19 | history | edited | Doc Brown | CC BY-SA 3.0 | added 4 characters in body |
| Apr 12, 2016 at 19:02 | comment | added | Doc Brown | @errantlinguist: in the case you described in your comment to Karl Bielefeld's answer, you seem to have all arguments on your side without the need for using the "performance". I would go a step further and say, if you argue about performance in such a case, you make a tremendous mistake, because your colleagues are right: performance does typically not matter there. Argue about simplicity, readability, maintainability, less lines of code, but not(!) about performance, not even as a side note. Don't offer them the possibilty of using Knuth against you. | |
| Apr 12, 2016 at 18:57 | comment | added | errantlinguist | Okay, that does make it clearer. However, I fear that I wouldn't even get a chance to "prove" that an alternative to a naive implementation is better because, as I stated, some people seem to kill any discussion about "performance" or "optimization" before they even hear it. | |
| Apr 12, 2016 at 18:43 | history | edited | Doc Brown | CC BY-SA 3.0 | added 654 characters in body |
| Apr 12, 2016 at 18:34 | comment | added | Doc Brown | @errantlinguist: maybe did I not make myself clear, or it is simply not what wanted to hear? My advice is: do not try using *philosophical arguments" of Knuth about "3%" or "97%". Keep it factual, otherwise your colleagues are most probably right that your performance arguments are inappropriate. | |
| Apr 12, 2016 at 17:44 | comment | added | errantlinguist | While good information, this doesn't actually answer my question on how to work with people who stonewall a discussion the minute it has to do with performance. | |
| S Apr 12, 2016 at 17:17 | history | suggested | Nathan Tuggy | CC BY-SA 3.0 | Fixed grammar and tweaked punctuation |
| Apr 12, 2016 at 17:13 | review | Suggested edits | |||
| S Apr 12, 2016 at 17:17 | |||||
| Apr 12, 2016 at 17:04 | history | edited | Doc Brown | CC BY-SA 3.0 | added 434 characters in body |
| Apr 12, 2016 at 16:57 | history | edited | Doc Brown | CC BY-SA 3.0 | added 434 characters in body |
| Apr 12, 2016 at 16:49 | history | answered | Doc Brown | CC BY-SA 3.0 |