Hacker News Reader

Comment by geophile | Hacker News Reader

> Having multiple perspectives on design.

Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.

View on HN

It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design.

If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from.

If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.

That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.

Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back.

Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.

"Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.

No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.

Yes. Code "is" design, unless you're working with machine code. Code is a blueprint, not the building. We sometimes tend to take high level languages for granted and forget that.

Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.

Why not?

For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things.

1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.

My experience is mostly server-side, and there, I have found that smushing these things together leads to sadness.

Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering.

Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.

Reply on news.ycombinator.com