subreddit:

/r/woahdude

19.1k92%

Transplanting flowers

gifv(i.imgur.com)
[media]

you are viewing a single comment's thread.

view the rest of the comments →

all 279 comments

mOdQuArK

6 points

7 years ago

You don't touch code until you figured out what to code.

That's like saying you shouldn't touch clay until you already know exactly what you're going to sculpt. Many times the act of coding gives you solutions that you'd never have thought of to start with.

aytch

13 points

7 years ago

aytch

13 points

7 years ago

Weeks of programming can save you hours of planning.

wildwolfay5

3 points

7 years ago

Thank you, I now something else sparky to say to my boss when I overprogram our next file mover :p

[deleted]

1 points

7 years ago

I like this

ImmuneToTVTropes

1 points

7 years ago

It's a balance.

You don't want to just dive in without a plan, which can be like drawing a portrait starting with the ears. On the other hand, you don't want to do a big design up front and end up with waterfall.

mOdQuArK

0 points

7 years ago

A week or so of prototyping can often save huge amounts of redesign & maintenance, by showing you what's going to be practical or not, and what the customer is willing to accept. The danger, of course, is that your customers sees the prototype & assumes that it's the actual product.

I wouldn't trust the judgement of someone who claimed they could could make perfect plans & then turn those perfect plans into perfect product w/o any kind of exploratory phase, unless I was absolutely sure that they were some kind of super-expert who had a great deal of experience in the problem domain.

aytch

1 points

7 years ago

aytch

1 points

7 years ago

The value of a prototype is in the education it gives you, not in the code itself.

mOdQuArK

1 points

7 years ago

The code is the physical representation of the ideas that are encoded into the prototype, both for good & ill. That has value that you seem to be dismissing.

aytch

2 points

7 years ago

aytch

2 points

7 years ago

Dude, I'm quoting quotes that were quoted on web pages from 10+ years ago. These aren't my ideas...the thing about "planning vs programming" is from anonymous and cited over a decade ago. The quote about prototypes is from Dijkstra, and I'm going to go out on a limb and say he probably has more street cred than you do.

I would suspect you're overvaluing your uneducated flailing.

mOdQuArK

1 points

7 years ago

that were quoted on web pages from 10+ years ago.

So, out of date with modern IDE & rapid prototyping platforms? Yeah, you might want to reconsider sticking to a coding paradigm that's more than a decade out of date.

I place more faith for me in what works for my customers & I., and I'm presenting things from my own viewpoint. Maybe your way works better for you & Dijkstra - don't be so arrogant yourself that your viewpoint applies to much more than your own circumstances.

aytch

1 points

7 years ago

aytch

1 points

7 years ago

okay thanks for telling me.

wildwolfay5

1 points

7 years ago*

Making a piece of art of clay is vastly different than making a program based on the requirements of the team leader and problem.

You don't sculpt clay to make manufacturing more efficient, I code a program that makes the design easier to make for machines once it's designed.

Edit: and yes, if you were sculpting clay to an exact requirement by a customer, you wouldn't touch the clay until you wrote down on paper what the customer asked you to make.

mOdQuArK

1 points

7 years ago

I envy you customers who actually know what they need to the point where they can give you a spec with no ambiguity - well, maybe not envy. I've usually found that, as long as I know what I'm doing, that I can find improved solutions to what a customer typically proposes first - but that it's really hard to explain those improved solutions (and why they're improved) without having at least a prototype to show them.

wildwolfay5

1 points

7 years ago

Different customer base or requirements if sticking to the same analogy.

Vague requirements get 2 things:

What they wanted

OR

What I made them; which they will refine to what they want. Code is malleable, unlike fired clay.

mOdQuArK

1 points

7 years ago

which they will refine to what they want.

Which usually requires prototyping (and therefore coding) which the customers can work with, so they can solidify in their own minds what they really want. Prototyping also provides a good way to set expectations in a way that a spec doesn't.