←back to thread

873 points belter | 1 comments | | HN request time: 0s | source
Show context
ZaoLahma ◴[] No.42947654[source]
> Most programming should be done long before a single line of code is written

Nah.

I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently.

Quite often you also have eureka moments with better solutions that just would not have happened unless you had code in front of you, which again makes you approach the problem entirely differently.

replies(16): >>42947849 #>>42948402 #>>42948536 #>>42948683 #>>42948786 #>>42949252 #>>42949429 #>>42949588 #>>42950167 #>>42950238 #>>42950409 #>>42953785 #>>42955243 #>>42956358 #>>42957524 #>>42964457 #
VyseofArcadia ◴[] No.42948536[source]
Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it.

Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.

replies(6): >>42948610 #>>42949170 #>>42949340 #>>42951151 #>>42956824 #>>42962429 #
devmor ◴[] No.42951151[source]
As someone who's spent 12 years working on legacy codebases, I strongly disagree with this.

Iterative work in a large legacy codebase is how you end up making your large legacy codebase larger and even less understood.

Your planning should "wade into the code" from the start. I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff".

Frankly, I'd say it's the opposite for greenfield development. Doing iterative work to build out a new product and make changes as you discover needs you didn't account for makes a lot more sense that flailing around making holes in something you don't fully understand that is tied to active business needs.

replies(1): >>42951819 #
9rx ◴[] No.42951819[source]
> I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff".

In terms of a broad population, I am not sure there is a meaningful difference, though. You can iterate on your ideas on the whiteboard or you can iterate on your ideas in code, but the intent is the same. Either way you are going to throw it all away once you have settled on what should be the final iteration anyhow.

It just comes down to where you are most comfortable expressing your ideas. Some like the visuals of a diagram, others are more comfortable thinking in code, some prefer to write it out in plain English, and I'm sure others carry out the process in other ways. But at the end of the day it is all the same.

replies(2): >>42952443 #>>42952932 #
1. devmor ◴[] No.42952932[source]
I have never really thought about it that way, but you're right.

Ultimately what matters is the final changeset. How you get there doesn't really matter.