181–190 of 349 posts
So it was not simple and it was not fast. Nobody wants simple.. ever.
Earlier quoted context omitted.
> Correctness is the destination of any piece of software "Good enough" is the destination of any piece of software. Sometimes that means correct, but more often it means "oh yeah, sometimes it starts acting funny, just restart it when that happens"
It never means "correct". Not to mention that 100% correctness is even impossible.
In which case please consider that everyone here is using "correctness" to mean "correctness that is achievable by reasonable human effort". :P It's easy to win any argument by taking one side to its logical extreme and asserting that it is therefore impossible, but that doesn't create a useful discussion. By the same logic we could assert that 100% simplicity is impossible, but that would be just as silly.
When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…
This may be a matter of definitions. It may be worthwhile distinguish between general correctness and full, as close to 100% provable correctness as you can get. That way allows us to dismiss clearly degenerate cases (you can always do a one-statement no-op program that will be simple but do nothing).
General correctness is what I want in most cases. Example: voice dictation. It requires a final read & polish, but errors are infrequent enough to save me a lot of time. Full correctness is usually requested for jet avionics, nuke power plant control, etc.
With that addition one should optimize for general correctness and simplicity as a first goal, full correctness and performance as a very distant second.
When I write software (or build systems) what I end up with is usually significantly different from what I started with; not externally, but under the hood. Keeping designs simple (on large teams being almost militant about it) helps large systems morph as it goes from a proof of concept into an actual thing. My 2c.
I always stress a hierarchy of Goals, Strategies, Objectives, and Tactics, which is a fundamental and well known way to tackle strategic thinking/planning. When you engage in fuzzy thinking, then it is easy to make the wrong decision. For example: "we must be agile". Well, no, that's not our goal. Our goal is "whatever", and agile might let us meet that goal, or it might hinder it. "Move fast and break things" will (hopefully) never be the motto of Boeing.
So, simple, correct, fast. That conflates different things. It is never my goal that things be simple. A goal might be 'correctness' or 'don't kill people'. A way to achieve correctness is, for example, easily unit testable software, which is a strategy, the objective is a passing unit test, and a tactic might then be the code be simple (low cyclomatic software is easier to exhaustively test, for example).
When you conflate various levels of this hierarchy bad decisions and religion ensure. "Code must be simple". "We must always be agile". "Everything must be documented". "functions must be For example, short functions are generally a good thing. But, sometimes it takes 50 lines to express a cohesive thought. Splitting that arbitrarily across many functions can just obscure intent, and leave the developer scrolling back and forth, which is proven to reduce comprehension and increase the likelihood of errors.
In short, if you use these three criteria, in this order or any order, I don't think you will end up making very good decisions because you at best only implicitly have stated and understood the problems you are trying to solve and the interrelationships of how your strategies and tactics affect one another/
Earlier quoted context omitted.
That 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.
Correctness is achieved by simplicity.
That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."
Earlier quoted context omitted.
The old yarn I'd heard for years is close to this. Make it work. Make it work right. Make it work fast. In that order. Now it could be argued that "work right" can be read as "make it (work right)", or "(make it work) right", or both, but I think the point of this saying is that the "fast" part should always come later.
Yep, this is the version I heard. I think the distinction between "make it work" and "make it work right" is important, though - where "work" means "solve the problem", and "work right" means "solve the problem in a robust and reliable manner." If your software doesn't solve the problem, it's useless, no matter how correct or fast it is. Once it solves the problem, then you can work on making it bug free and elegant.…
Earlier quoted context omitted.
That's not what Coq would do, and a misrepresentation of Dijkstra's position. We certainly could use tools like TLA+ to assist us with existing code. Folks are using "simple" and "easy" interchangeably here. That's probably inappropriate.
I apologize for using Coq speicifically, I just needed a scapegoat for formal verification that people might have actually ever heard of. :P I'm happy to debate definitions, which the author of the OP has regretfully omitted (and the contentious definition here is probably the OP's notion of correctness, rather than their notion of simplicity).
When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…
> Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness This may be a matter of definitions. It may be worthwhile distinguish between general correctness and full, as close to 100% provable correctness as you can get. That way allows us to dismiss clearly degenerate cases (you can always do a one-statement no-op program that will be simple but do nothing). G…
Which is the root of the endless back-and-forth in this thread: a program has to do what it says on the tin ("general correctness") before anything else, and then probably be as simple and as "fully correct" as possible. But it's easier said than done for us to posit a distinction between general and full correctness than to actually find exactly where the dividing line lies between the two. A blog post to discuss such a dividing line might have been valuable, but the one we've got here unfortunately just handwaves away all the hard questions.