And Hard to do the Wrong Thing
With developers, you always need to make it dead simple to do the right thing. If the right way is the hard way, we will always take shortcuts and not do things the right way. At the same time, even if the right way is easy, but a wrong way is either just as easy, or maybe slightly harder, we will likely always choose the wrong way (maybe that’s just hindsight though). We find it remarkably easy to convince ourselves that we don’t need to check for certain exceptions, or guard against null values, or that we can build this faster if we don’t write any tests.
The right way must be the default way, where the simplest, brain-deadliest, thing to do is the right thing. We must have to do work to go around to the wrong way, and jump through numerous hoops to get there. Otherwise, the software will end up in a big ball of mud.
How many blocks need to be in place is determined by the discipline and maturity of your team and company. Some may be able to just have a shared agreement in the team on code practices. Some may need strict enforcement of static analysis tools. It can take time to find the appropriate balance between working code, developer time, and code cleanliness/maintenance.