6 ms·
Your example is a case of premature optimization. That is not what the author is concerned with. The problem are not the programs that obviously do not work or
by jpfr 8y ago
Your example is a case of premature optimization.
That is not what the author is concerned with.
The problem are not the programs that obviously do not work or who break in a very visible fashion.
Programs whose deficiencies are known can be fixed or worked around.
The real problem are programs that appear to work correctly but aren't.
To say it with the words of Tony Hoare:
There are two ways of constructing a software design:
One way is to make it so simple that there are obviously
no deficiencies, and the other way is to make it so
complicated that there are no obvious deficiencies. The
first method is far more difficult. It demands the same
skill, devotion, insight, and even inspiration as the
discovery of the simple physical laws which underlie the
complex phenomena of nature.
Source: 1980 Turing Award Lecture; Communications of the ACM 24 (2), (February 1981): pp. 75-83.
- kibwen 8y agoThat quote actually refutes the OP by reinforcing that correctness is more important than simplicity. Achieving correctness is the whole point of making things simple, after all. To put simplicity before correctness would be missing the forest for the trees.
- jpfr 8y agoCorrectness is achieved by simplicity.
- kibwen 8y ago> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."
- jpfr 8y agoThat's... literally what the author said. If your solution is not simple, it will not be correct or fast. Correctness may be the end-goal. But correctness is absolute. So it is a bad performance indicator to set as the goal. Yes, we can track bugs. But the absence of open bugs is no guarantee for correctness. I can never say "We are 5% more correct than last week. Keep up the good work!" Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change.
- kibwen 8y ago> That's... literally what the author said. Excellent, so we both agree with the author that correctness is the ultimate point and that simplicity is just a useful tool for achieving correctness. :) > Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change. How does one purport to measure simplicity?
- nickpsecurity 8y agoI was considering ASM's for it: http://pages.di.unipi.it/boerger/Papers/Methodology/BcsFacs07.pdf http://pages.di.unipi.it/boerger/Papers/Methodology/BcsFacs0... My thinking was like this. The complexity of software is synonmyous with us saying we don't know what it will do on given inputs. As complexity goes up, it gets more unpredictable. That's because of the input ranges, branching, feedback loops, etc. So, a decent measure of complexity might be simplifying all that down to purest form that we can still measure. The ASM's are a fundamental model of computation basically representing states, transitions, and conditionals making them happen. So, those numbers for individual ASM's and combinations of them might be good indicator of complexity of an algorithm. And note that they can do imperative and functional programming. What you think of that idea?
- guiambros 8y ago> ...reinforcing that correctness is more important than simplicity It's the other way around. Correctness is obviously the goal (and likely performance too, depending on your use case), but the way to achieve it is through simplicity. So simplicity should be prioritized - as it allows you to ensure correctness.
- kibwen 8y agoI'm glad that we can agree that correctness is the goal, though I still take umbrage to the blog post's title, thesis, and conclusion. :P
- optimuspaul 8y agoI think maybe you mistakenly assumed that response was in opposition to your comment, I read it as a simplification and restatement of what you said.
- jpfr 8y agoWe reached the maximum thread depth. >> Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change. >How does one purport to measure simplicity? There's 40 years of research into that. And loads of tools to support dev teams. You can start here: https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity Also related are costing models: https://en.wikipedia.org/wiki/COCOMO https://en.wikipedia.org/wiki/COCOMO
- kibwen 8y agoWe also have 40 years of research into improving program correctness, e.g. static analysis, test suites (unit, integration, etc.), fuzzing/mutation testing, and the benefits of code review. The idea that simplicity (which I'm pretty sure that nobody in here is using to specifically mean "the lack of cyclomatic complexity") can be measurably improved but that correctness cannot is incorrect.
- jpfr 8y ago> The idea that simplicity (which I'm pretty sure that nobody in here is using to specifically mean "the lack of cyclomatic complexity") can be measurably improved but that correctness cannot is incorrect. Have you seen a program that comes with a formal proof of correctness? I have. And boy, they are really simple. The end result can be complicated. But the program is broken up into small, simple, easy-to-understand pieces that are then composed. http://spinroot.com http://spinroot.com https://frama-c.com https://frama-c.com
- nickpsecurity 8y agoDerek Jones argues McCabe Complexity and COCOMO were scientifically unsupported with little bandwagons pushing them for reasons of fame and/or funding: http://shape-of-code.coding-guidelines.com/2018/03/27/mccabes-cyclomatic-complexity-and-accounting-fraud/ http://shape-of-code.coding-guidelines.com/2018/03/27/mccabe... http://shape-of-code.coding-guidelines.com/2016/05/19/cocomo-how-not-to-fit-a-model-to-data/ http://shape-of-code.coding-guidelines.com/2016/05/19/cocomo...
- ythn 8y agoYes but I think OP is saying that, paradoxically, prioritizing correctness over simplicity actually makes correctness more elusive than if simplicity were prioritized.
- a1369209993 8y agoBy that logic, "fast" goes before "correct"; you can't print the answer quickly if you don't have the answer, after all. > if your solution is not simple, it will not be correct or fast. The point of the article is that "simple" is a prerequisite of "correct" (and "fast").
- madhadron 8y agoNo, that's just the easiest path to it if your only tool is an unaided human brain.
- hinkley 8y agoFor every problem there is a solution that is simple, neat - and wrong.
- mannykannot 8y agoIndeed - for example, you can make things look simple by leaving necessary parts out. I think, however, that the more important part of this quote are the words 'problem' and 'solution'. Until you have an understanding of the problem that is correct, it is unlikely that you will come to a solution at all. Avoiding the introduction of gratuitous complexity is not necessary to reaching that understanding, but it sure helps.
- krapp 8y agoClearly, that solution isn't simple enough.
- hk__2 8y agoThat doesn’t mean simplicity is more important than correctness. The simplest program ever is an empty file, and it doesn’t solve any problem.
- tzm 8y agoIn terms of designing solutions, I would say that "correctness" is relative to the problem statement at hand. It's also a degree and not an absolute. It may be correct and incorrect at the same time, depending on the context. From this I would prefer simplicity over correctness to allow for ease of optimization.
- icc97 8y ago> Your example is a case of premature optimization. That is not what the author is concerned with. I think he is. Premature optimisation is putting the order: fast, simple, correct. So although the author doesn't explicitly state it, premature optimisation is something that would be avoided if you followed his advice.
- karmakaze 8y agoDepending on interpretion of terms, I'd agree with either simplicity or correctness first. To disambiguate I would say: Working, simple, correct, optimized.
- nojvek 8y agoWould deffo agree to this. My approach is usually sending out a PR as soon as I can to a group of reviewers / users and goes in following stages. 1) POC - proof of concept. It does 90% of things, some parts are ugly and messy but validates a hypothesis. The unknown unknowns are discovered. I want to stage this and get this in front of some alpha internal users as soon as I can. First pass reviewers give a on the plan of attack. Lots of sub TODO’s are listed in PR. The goal is to discover edge cases and unknown unknowns. 2) Simple - Go through PR and refactor any existing / new code so it’s readable and DRY. If reviewers don’t understand the “why” of some code, a comment is left. Now 90% of scenarios are covered, probably some edge cases may not work but the edge cases are known. The code is simple and at right layer of abstraction. 3) Correct, Testable - Edge cases are covered, tests are written, internal users have validated that the feature is working as expected. 4) Polish - if it’s slow, then slow internals are swapped out for fast parts. Tests would mostly work as is. Same with UI, css fixes to make it elegant and pretty. Sometimes the process is a day, sometimes it’s a week.