The author misses the point of abstracting portions of systems away. First, you can create shim layers for unit, component, and functional testing. Many of thes

The author misses the point of abstracting portions of systems away. First, you can create shim layers for unit, component, and functional testing. Many of these tests can be automated, without the need of a database, or other functionality required during deployment. Next, if your software is written for you, and only you, then you're losing on others using it or other customers. Customer A might not use DB 1. Customer 2 might use DB1 at certain locations, and DB2 at others. The abstraction portion also gives a tester the ability to see if what comes in, is what needs to come out, without reliance on additional hardware and other sunk costs. A simple example is a currency/bill validator. These are expensive pieces of hardware, and not needed to verify other portions of the system, but a module for that device can be emulated. Next, it appears he hasn't read the book Pragmatic Programmer, or the book went over his head. "Don't live with broken windows", "Make it easy to reuse", and "Decoupled code is easier to change" are three hallmarks of the book. All three are in contradiction to his article. If you haven't read the Pragmatic Programmer, I highly encourage you to read it. It is a required read in my company.