| > If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing. The win isn't that you saved fractions of a second. It's that your quick edit was fast enough that it didn't interrupt your thought process. > As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write. You say this like trial-and-error isn't a valid way to design something. You can spend as much time as you want designing things up front, but until you try them, there's a good chance you won't know if it's a good design. You'll always find issues later on. Another way to look at it is this: you could write down you ideas on paper or in diagrams, or you could write them down in code, and run them to see if they make sense/work the way you think they should. The code you write while designing doesn't have to be the same codebase as the final product. It can just be a bunch of small programs you use to help formulate your ideas. |
That's not because I am a genius or somehow super-human, I have a lot of experience and have developed a decent process of design-before-coding. Trial and error is really wasteful. It still has it's place in areas that might not be entirely clear. Outside of that, design-before-coding can save tons of time and aggravation.
In other words, coding is the end of a process, not the process.