There are two schools of thought in programming I have seen.
1. Design it right the first time, tests and all.
2. Build a throwaway, no tests, little refactoring as you quickly iterate
Programmers who fall into category 1 in my experience mistakenly believe that they understand the requirements of the software they are writing. Category 2 programmers tend to be ones who actually deal with users/real world, and know that they don't understand the requirements.
My position is that if you are building something for the first time, you are going to get it wrong, so get it wrong as quickly and cheaply as possible. This means getting it in front of users as quickly as possible, bugs and all.
I find there's a balance to be struck. You want to get stuff in front of users quickly, but if that stuff sucks so much that it's unusable, you aren't going to release it (and if you did, nobody would use it). So you want enough tests that you can be reasonably confident of the code and not spend a lot of time debugging, since debugging is the real timesink that'll kill you.
I often find that I unit test all but the latest layer. As soon as I start depending on code from something else, it's time to write some tests. But if I just wrote something, it's probably in flux and tests would just prematurely lock down the interface. Write the code, write the client (which probably requires that you rewrite the code), and then write the tests in lieu of debugging the code.
Also, to get something in front of users, you rarely need to be doing anything remotely complex. It's not like writing a disk based inverted index or a filesystem. When writing tools like those, obviously testing is important.
I'd love to see some research on this. I would hypothesize that there is a point of problem complexity where the lack of tests becomes a negative for productivity.
I second this suggestion (and agree with the hypothesis, although its probably not just a function of raw problem complexity, other variables must come into play)
Hasnt it been done already? Couldnt find anything I would class as 'scientific' with a quick google search. Would be a good thesis for someone.
1. Design it right the first time, tests and all.
2. Build a throwaway, no tests, little refactoring as you quickly iterate
Programmers who fall into category 1 in my experience mistakenly believe that they understand the requirements of the software they are writing. Category 2 programmers tend to be ones who actually deal with users/real world, and know that they don't understand the requirements.
My position is that if you are building something for the first time, you are going to get it wrong, so get it wrong as quickly and cheaply as possible. This means getting it in front of users as quickly as possible, bugs and all.