“I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.”
As a CS student currently at university, my experience has been identical. I also can’t help but notice a similarity between these ideas and the methods of agile software development, where at each iteration you produce a working approximation of the final software, taking into account new information and new specification changes as you go.
The people who taught you to architect programs before coding were also aware of this trade-off.
It’s a lot easier to write the small programs assigned in college that way, than the large programs you will write in the real world.
This is not the top-down vs. bottom-up debate; both top-down and bottom-up design architect first.
It is related to the concept of waterfall/iterative/incremental design; incremental designers can paint themselves into a corner.
I’ve written a lot of big programs, and I’ve never regretted the time spent architecting them. I have sometimes wished I had spent more time designing them before starting.
Fatal design errors that crop up down the road are more likely to be language-related: Your program gets so complicated that you have to rewrite it in a compiled language to run it in real-time or to avoid running out of RAM; or you discover that C++ templates don’t work as advertised, or that Java can’t allocate 2G of RAM, after you’ve already writtten 3000 lines.
Paul Graham said something very similar about figuring out a program:
“I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.”
As a CS student currently at university, my experience has been identical. I also can’t help but notice a similarity between these ideas and the methods of agile software development, where at each iteration you produce a working approximation of the final software, taking into account new information and new specification changes as you go.
The people who taught you to architect programs before coding were also aware of this trade-off.
It’s a lot easier to write the small programs assigned in college that way, than the large programs you will write in the real world.
This is not the top-down vs. bottom-up debate; both top-down and bottom-up design architect first.
It is related to the concept of waterfall/iterative/incremental design; incremental designers can paint themselves into a corner.
I’ve written a lot of big programs, and I’ve never regretted the time spent architecting them. I have sometimes wished I had spent more time designing them before starting.
Fatal design errors that crop up down the road are more likely to be language-related: Your program gets so complicated that you have to rewrite it in a compiled language to run it in real-time or to avoid running out of RAM; or you discover that C++ templates don’t work as advertised, or that Java can’t allocate 2G of RAM, after you’ve already writtten 3000 lines.