Simplicity of means (of your ways of doing things) is only part of your overarching strategy for software development. You must always add simplicity of goals.

Imagine you are finding a difficult problem using or configuring some 3rd-party library. Let's say this is open source, so you can change things if you need to.

You can ask for help, either in paid support or the Net. Either way, you now induct a member of another community temporarily into your development organization and deal with all the levels of confusion. The process promises to go on for some time.

This is an Awakening: a development organization that Can't Help Itself Needs Help. You commit to research the problem yourself and plan to fix it yourself.

You have achieved Simplicity of Means.

You read docs, look at code, write test cases. You realize that you should write the functionality yourself.

You have reached the twighlight frontier between Simplicity of Means and Simplicity of Goals.

As you write your own library, you realize that this, too, isn't worth it, because what you were trying to achieve that got you to adopt the original problematic 3rd-party library is not worth doing in comparison to other productive activity you could be spending the same amount of time, effort and resources on. You change what you were trying to do.

You have achieved Simplicity of Goals.

Some organizations which are finally cornered into simplifying their goals feel they have suffered a defeat. In reality, they have achieved a victory.