A series of short articles exploring the impact of writing tests after the code is written on the implementation part of SDLC.
Sin No.1: Production Code First.
By not writing tests upfront, the code becomes most of the times a Transaction Script. It usually lives at application boundaries. If not, then it usually delegates all method arguments to a method with the same name inside a Service Layer.
Most of the times, this code is responsible for aspects such is validation and persistence violating the SRP and likely most (if not all) of the other principles of class design.
Even worse, inside those methods, dependencies might be resolved using a Service Locator (which is not good) forcing us to mock the container (if that's an option at all) in order to successfully write unit tests afterwards.
At the end, a lot of time is spent to write a few Fragile Tests, resulting in a system which is (in most other places) not covered by tests at all.