De Nosolosoftwarewiki
Iterative development
The picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic.
No system has ever been development in that way, and probably none ever will. Event the small program developments shown in textbooks and papers are unreal.
They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen.
-- David Parnas and Paul Clements, on A rational design process: how and why to fake it
Related concepts
The simplest thing that could possibly work
So when I asked [KentBeck], "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?"
I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen,
instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it.
If it needs to be more, we can make it more.
-- Ward Cunnigham, on A conversation with Bill Berners
Related concepts
- Keep it simple stupid (KISS)
- You ain't gonna need it (YAGNI)
Given enough eyeballs, all bugs are shallow
My original formulation was that every problem ``will be transparent to somebody``. Linus demurred that the person who understands and fixes the problem is not necessarily
or even usually the person who first characterizes it. ``Somebody finds the problem,`` he says, ``and somebody else understands it.
And I'll go on record as saying that finding it is the bigger challenge.`` That correction is important; we'll see how in the next section,
when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.
-- Eric S. Raymond, on The cathedral and the bazaar
Related concepts
