DEV Community

Discussion on: Should Coding be Trivial?

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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.

for each desired change, make the change easy (warning: this may be hard), then make the easy change

He goes on to say underneath it "Sometimes when the work is hard it signals that we're doing it wrong. Sometimes it's just hard."

I've experienced this many, many times. I started coding and realized there is some hairy edge case that is going to make the code difficult. As a beginner, I would just power through that, and it would turn out to be a source of friction/bugs/support questions later. Nowadays, those cases immediately raise my suspicions that I have misunderstood something. 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.

So I agree with Lamport's statement that coding should be the more trivial part. Many of the hard problems can be addressed by gaining an accurate understanding and working through solutions outside of coding. (That funny saying: "Weeks of coding can save hours of planning.")

If the coding is a lot of effort, then it should be because the problem itself is a lot of effort. Not because the mechanics of the implementation make it so.

Collapse
 
fpuffer profile image
Frank Puffer • Edited

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.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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.

Thread Thread
 
fpuffer profile image
Frank Puffer

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+.

Thread Thread
 
kspeakman profile image
Kasey Speakman

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.