1) TDD encourages testing the smallest unit of functionality possible
2) When you are first developing a large piece of functionality from scratch, you often need to upend the entire architecture a few times as you solidify the design. Theses revamps are the type of thing cannot be done incrementally as large number of small changes. And doing design on paper in advance only goes so far. And these architectural revamps are best done early, as they are far easier to do when you have 1000 lines of code than when you have 100000 lines of code.
3) smallest-unit-of-functionality tests generally get throw away in system-wide revamps
4) Therefore, the cost of these high-level revamps is greatly increased if you need to throw away all these tests every time, hindering productivity.
5) Because of that, I write tests afterwards, once i am comfortable the architecture has stabilized.
TDD is an methodology, not a religion. Do what works best for you and the specific project you are working on.
If you work for the government in Australia, you probably want the OPPOSITE of what this is - cloud servers hosted entirely outside the USA. If the servers are located in the US, they are potentially subject to the US patriot act, and i doubt that would pass Australian government privacy regulations
'There is a direct and measurable causal relationship between number of LOC and number of bugs.'
So if i write unit tests, that increases the number of lines of code, thus increasing the bug count right? The static type information in java is more akin to unit tests than actual programming logic - they decrease the bug count, not increase it.
Whether they decrease the bug count enough to make up for the productivity loss is the part that is debatable
Some of their arguments seem debatable, but my biggest issue with stored procedures with Oracle is purely economic - It is MUCH cheaper to scale the application layer than to scale the database layer. Therefore, if you want to scale cost effectively, and you want to use Oracle, you should put as much logic in the application layer as possible.
The article says 'if you have millions of users, you should be able to afford decent hardware.' - that is misleading, because the cost of the hardware is miniscule compared to the cost of the Oracle licenses you would need.
I have to say that i really like the looks of this language (at least as much as i can without having programmed anything in it) - it seems to fix all the major problems with java, without completely changing the paradigm.
And while I love scala, i like this language even more, since scala's implicits are a bit too 'magical' for my taste, and I think it scala overvalues terseness at a cost of readability
1) TDD encourages testing the smallest unit of functionality possible
2) When you are first developing a large piece of functionality from scratch, you often need to upend the entire architecture a few times as you solidify the design. Theses revamps are the type of thing cannot be done incrementally as large number of small changes. And doing design on paper in advance only goes so far. And these architectural revamps are best done early, as they are far easier to do when you have 1000 lines of code than when you have 100000 lines of code.
3) smallest-unit-of-functionality tests generally get throw away in system-wide revamps
4) Therefore, the cost of these high-level revamps is greatly increased if you need to throw away all these tests every time, hindering productivity.
5) Because of that, I write tests afterwards, once i am comfortable the architecture has stabilized.
TDD is an methodology, not a religion. Do what works best for you and the specific project you are working on.