loading...

re: Should Coding be Trivial? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I first heard of Leslie Lamport via distributed systems. (vector clocks, Paxos, etc). I take his quote to be analogous to one of Kent Beck's tweets...
 

Sometimes when the work is hard it signals that we're doing it wrong.

But to find it out, you have to start the (coding) work. This is another type of feedback you only get when starting to code. As long as you just write specs and draw diagrams, things tend to look simple.

I started coding and realized there is some hairy edge case that is
going to make the code difficult.

Again, you had to start coding to realize it.

So I stop coding and go talk to people (customers, the team) and try to
get clarification (especially answering "Why?"). Then I think about
different strategies and work through scenarios (verbally, whiteboard,
notepad, etc.) It is surprising how many times, after coming to a better
understanding of the problem, that I can simply approach it from a
different angle and the hairy edge case no longer exists.

Actually this is exactly what I'd recommend: You start coding, find an issue, step back and think about it, maybe draw some diagrams, resolve the issue, go back to coding, find other issues and so on.

But I have the impression that Lamport suggested to delay coding as much as possible. That's what I don't understand. Because unless you don't start, you won't get much feedback.

 

I didn't hear the talk to get the full context. Do you have a link?

Nowadays, most everyone does (or wants to do) some permutation of Agile. That supports the kind of process you are talking about. (And what I was also referring to.) However, traditional engineering goes through rigorous specification and design (and testing and nowadays simulation). And during some span of time software was approached in that way. And probably safety/security critical software often still is, because the cost of failure is high. So either perspective can make sense depending on the problem domain.

Also bear in mind that Lamport didn't just make programs but helped make Computer Science itself up to this point. So he probably has an engineering background.

The quote is from this podcast.

It is mainly on TLA+, a formal specification language for concurrent systems that he developed. I didn't mention this in my original post because I don't think that many people (including myself) are familiar with TLA+.

Ah, yes. That is a language for formal verification. Seems like kinda the same principle as TDD, but taken to the level of mathematical proof. You write all the assumptions about the inputs and outputs and side effects of methods. Then you write the implementation. Then the verifier attempts to mathematically prove your program is correct. Yeah, it seems like at that point most of the work would be in defining the assumptions.

Code of Conduct Report abuse