"If it ain't broke, don't try to fix it." I'd guess it's because something done right has been done, finished, completed, works fine, not interesting any more. Something which is wrong needs fixing.

Unit testing will check the set of code paths that you write the tests to exercise. Fine if you're testing small methods, with only a few possible code paths or edge cases. Then you need to test interactions between your classes, each of which has a dozen methods with 2-5 paths each. Suddenly you have tens of thousands of tests, most of which differ in very small ways. A strong type system enables invariants to be proven efficiently, regardless of the number of possible paths through the code, because it does not need to rely on executing every possible path. A type system is not a replacement for unit tests, and unit tests are not a replacement for a type system.

I think what he was getting at is that 'professional' says nothing about quality of work, only that the person is paid to do it .

In the middle of a 1700-line JS file: // <magic type='black'> [... 150-line Javascript function, returning a factory function to create and track state for a UI widget which, strictly speaking, should not work ...] // </magic> Some time ago, that same file started with a comment along the lines of: // abandon hope all ye who enter here I think I may have to restore that comment.

To paraphrase someone on Usenet: It's an Enterprise application if the vendor freebie is a red shirt.

There's the old way, and the new way. In both cases, databases exist on a per-machine basis. For our current version, we have a large number of SQL scripts run by a special tool. It also inserts sample data. Maintaining it can be... fun, although we've hit no real problems yet. For the new version, the app itself is capable of generating or synchronising the entire schema from interface definitions in an assembly, and sample data can be added automagically too.