Suppose you are writing a business contact program (or maybe a service, platform, etc). So, the scope of the program, its reponsibility, the one thing you want it to do well so that you will have people using the program (and maybe hopefully buying it or paying your subscription fee), is to manage business contacts. However, you will probably break down "managing business contacts" into various features, e.g., intuitive adding of a contact, search functionality, ability to send email, track tweets, social network connections, whatever.
Does this mean that your program will do many things? Obviously. Yet, in doing all these, it does that one thing that you set out for it to do. There is no contradiction. It is just a matter of levels of abstraction. At another level, if you are going to program the adding of a contact, you may well break it down into different functions, e.g., to perform input validation before adding the contact.
Likewise, there is no contradiction in the example from post #1: the pay function abstracts away the payment of all employees who need to be paid. The payIfNecessary function abstracts away the payment of a single employee who needs to be paid. If you have the pay function directly perform the payment of a single employee who needs to be paid, then at that level of abstraction (or lack thereof), it does two things: the payment of all employees, and the payment of a single employee. If you abstract the latter away through a function call, then at that level of abstraction, the pay function does one thing: the payment of all employees only, with the payment of a single employee delegated to another function. Hence, someone reading the implementation of the pay function can see that the pay function is correct, on the condition that the function(s) that it calls are correct, without having to go into the details of those functions (unless he/she needs to), due to the abstraction.
That is elaborated (negatively, in my opinion), by Robert Martin's calculateAndDeliverPay example function. It breaks down the payment of a single employee further by abstracting away the calculation and delivery of payment, but I argue that this is unnecessary and can incur a mental cost for which there is no real benefit, since the abstractions provided by the functions it calls are already sufficient, in my opinion.Originally Posted by megafiddle