Simple, correct, fast: in that order
I can&#x27;t really understand the equivocating tone a lot of folks are taking in response to this, and more importantly I can&#x27;t wrap my head around how you could make such a statement in the first place: without correctness you&#x27;ve got nothing. Stating authoritatively that correctness comes after...anything is incomprehensible to me.<p>It&#x27;s possible to have a correct solution that is neither simple nor fast, and it can be worth your while to speed up a correct solution while sacrificing simplicity. So there are trade-offs involved in the relationship between simplicity and speed, but correctness is not negotiable. Acknowledging that all software has bugs is not the same thing as throwing out correctness as your first and primary objective in implementing an algorithm, and accepting that your solution may only be partial or fail with certain inputs is fine if that is acceptably correct for the problem at hand, but ascertaining that still comes <i>first</i>. Preferring simplicity over complexity because it makes debugging, profiling, etc. easier is not a reason to insist that correctness can go out the window in service to simplicity--who cares if you&#x27;ve removed all the bloat from your code if it&#x27;s <i>wrong</i>?