Which part. The model? The article explained it well enough. I think of it as two main parts: (1) make fewer bugs, and (2) show your users the correct way to do things (which is the inverse of getting the correct requirements).
Or are you asking what took me fifteen years to understand?
Dan basically planned the whole thing. When the whole thing was too big, he would break off a piece that wasn't and develop it as a wholly separate thing.
I understood this strategy worked, but I didn't fully understand why this strategy was successful until I realised source code matters more than I thought[1]: If your program is short enough, there won't be any bugs in it. This is why learning how to read and write dense code[2] can make your programs better -- and that's what I learned how to do[3].
Or are you asking what took me fifteen years to understand?
Dan basically planned the whole thing. When the whole thing was too big, he would break off a piece that wasn't and develop it as a wholly separate thing.
I understood this strategy worked, but I didn't fully understand why this strategy was successful until I realised source code matters more than I thought[1]: If your program is short enough, there won't be any bugs in it. This is why learning how to read and write dense code[2] can make your programs better -- and that's what I learned how to do[3].
[1]: http://www.jsoftware.com/papers/tot.htm
[2]: http://www.nsl.com/papers/origins.htm
[3]: https://github.com/geocar/dash/blob/master/d.c#L62