Zooming in on check 4, ask 'why' until you find the root. For some reason I tend to do this almost naturally, with mixed results though.
Especially when reviewing code, you often see how things can be done more simply, and asking "why" to the reviewee can sometimes backfire because of touching a sore point.
Thinking about it, not only when reviewing code. Also, when you question the used processes you often bump into "we found out from experience this works best" or "why change a working process". So always using the "why" tactic can be frustrating at times.
Asking why has to be done much earlier in processes than that. You need to interrogate the person or department that is asking for something to get to the thing that they actually need instead of merely what they think is the easiest thing for you to deliver.
I was often able to reduce the scope and cost of parts of projects by pestering the domain experts who wanted something to explain why they wanted it. I often discovered that they believed that what they really wanted was impossible or too difficult so they had pre-emptively asked for the second best. Once I understood what they really needed I could tell give them a proper estimate of the cost of solving the actual problem.
In some cases I was able to automate away the job that they had asked me to merely provide a better user interface for for and do that with less effort and cost.
It was mostly a long time ago so the details are a bit hazy now. Generally it went something like this:
The domain expert (our internal customer) has a badly specified procedure for picking the correct configuration for some sub-assembly. It depends on a number of different parameters some of which are continuous variables and some are discrete. Which continuous variables are relevant depends on which combination of the discrete values are chosen; for instance choosing nominally equivalent parts from different suppliers can mean having to express the specification in different terms. So the customer asks for a user interface that will make it easier for the end user (not the domain expert, a less qualified person) to explore the database and a few simple tools to do some calculations so that they can decide which parts to order.
While writing up my proposed solution I realize that a lot of what the domain expert has expressed as matters of fine professional judgement look suspiciously like they are in fact rule bound from the point of view of the actual end user. When I quiz the domain expert about this they tell me that they though that the task was too complicated to automate. When I finally extract from them the actual rules I see that the actual end user has no real freedom of choice, that the rules change about once a decade, and that all that is requires is a small form to gather the two pieces of information that are not already in the system and a fairly small set of database queries. All the rules can be encoded easily in a couple of small database tables that the domain expert can update when the conditions change.
I point out that this is actually less work, can be delivered sooner, and is most likely more reliable. The domain expert agrees and we are both happy.
Over the decades that I spent writing applications I frequently found that customers failed to ask for what they really wanted because of mistaken beliefs about the relative difficulty of various kinds of computing tasks. Instead of asking for what they needed they asked for what they thought we could provide. This frequently caused more delay than if they had simply asked for the best solution from their point of view.
Often the customer asks for what they want rather than what they need. Very often what they want is rooted in solutions or partial solutions that they have seen or implemented themselves. They think that they simply need a better version of their own home grown tool when in fact their tool is the way it is simply because of the limitations of the tools they had to hand, usually Excel programmed by someone doing it instead of the engineering that they are actually competent in. Using the appropriate solution, often an SQL database and a very simple front end, simplifies the task dramatically and makes the tool both easier to use and much simpler to maintain.
Especially when reviewing code, you often see how things can be done more simply, and asking "why" to the reviewee can sometimes backfire because of touching a sore point.
Thinking about it, not only when reviewing code. Also, when you question the used processes you often bump into "we found out from experience this works best" or "why change a working process". So always using the "why" tactic can be frustrating at times.