Like it or not, we humans make mistakes. If we embrace the fact that we are going to make mistakes, we can direct our efforts to reduce mistakes in areas that are critical in exchange for potentially making more mistakes in areas that aren’t. Gasp! We need to get over the silly notion that our work can ever be 100% perfect and try to maximize in the areas that matter.

Does it really matter?

These are the things I’ve found that typically don’t matter as much in the grand scheme of development. Start training yourself to identify areas that matter!

Infrequently used features

Especially if there’s an easy workaround during a failure

Administrative crud pages

Especially in smaller apps, the developer is usually the admin and can just hack at the DB in a failure

MVC Controllers

Extensive, stubbed out, mock style tests of controllers (MVC) – if a controller action fails to execute, is the world going to come crashing down?

Here are some blog posts (failblogs IMHO) on this topic. What value are we adding with all this ridiculous test code that is more complicated than the code we are testing?

Testing Route Data with Helper… really this is a smell that the routing API is not readable and not simple enough.

Logging

This just means debugging will be a bit harder and I’m sure we’ll fix it quick enough.

User management / authentication

Development typically involves logging in daily, so it’s likely we’ll catch the mistakes.

Please just use OpenId already or another common alternative to rolling your own.

If no one can login, deploying a fix won’t interrupt anyone!

Easily fixed/deployed features

Any feature that isn’t critical, that can easily be fixed and deployed.

CSS and images

How many of the things we do with CSS and images are just for aesthetic purposes and really don’t matter if the application still functions?

Do I really care if my bank sends me a statement and their logo shows up a red X?

Reports versus entry

If we allow a change (like a balance transfer) to occur that is invalid, it’s probably a bigger problem than if we accidently show an invalid balance total on a statement report. This is highly subjective, but I’m more worried about data going into my systems than data coming out, except where data flowing out flows into other systems.

Features that are no longer used / should be removed

Areas where testing seems to slow down development

IMHO, testing typically slows down development in areas that don’t matter (stubbing controllers/services, duplicated/overlapping test cases, KISS code) In areas that are important, we typically find complexity, and testing often helps avoid bugs in complexity faster than F5 debugging.

KISS

In the areas that don’t matter, we should strive for simplicity. Readable and simplified code is less likely to contain mistakes. Controllers can be thin instead of fat. Reports can isolate complexity in a tested model or functional components of reuse (calculations).

What does this mean?

So we know what doesn’t matter as much, what does that mean? For me it means less testing:

Not writing automated tests (or very few) … integration or unit

Not double/triple checking my work

Sometimes compiling is good enough

Sometimes a quick run of a common scenario on a related page, but not all scenarios

Rarely, the occasional bat shit crazy refactoring with little regard to these areas.

Conclusions

Some of this may sound radical, if so, don’t adopt it. I can refactor a lot faster if I know where I can run versus where I should crawl. Always crawling (extra effort is expended upfront) is as reckless as always running (extra effort is expended after the fact), an optimum is usually found in balancing what can and what shouldn’t break.

Sadly, I’ve seen a lot of hugely beneficial refactoring passed up simply because it would be invasive to areas that ironically aren’t that important in the grand scheme of things.