Code and coding is obscure:
With design - what you see is generally what you get, strategy work is easily documented, so it is not hard to see progress and apply quality control, particularly if you are an experienced person in the field. However, programming is not that visible or obvious. It is hard for someone who is not familiar with it to control progress and check quality. Ongoing monitoring of the progress is critical, find problems before they become big problems. Ideally this is done by someone who has a clear insight into the overall architecture and vision of the product and the overall strategy.
Programming is complex and can be inflexible:
The specifications of a project define the architecture of the system and affect how features are developed and often features are interdependent. (look at that last sentence again - seems a bit complex?). What I am trying to say is that when a feature is designed to work a certain way and then there is a change (or a misunderstanding at the planning stage), it can be costly to apply, affect delivery times and increase frustration and tension to all involved. Mitigating this comes down to using an experienced lead who would design a system that is flexible where it needs to be, provide for expected future needs while remaining practical and feasible, and employing the appropriate methodologies for managing the project.
Programmes are… programmers:
Some programmers can write amazing code and communicate with great clarity both with work mates and with the client, ‘get’ the client’s business direction, aspiration and future needs, self motivated and never get distracted. However, most do not possess all these attributes. A good programmer should be exceptional at programming, researching and learning relevant patterns and technologies. For the rest - get someone who is excellent at managing programmers as well as ‘getting’ the client (they are bit rare as well :) )
Support
So the project is finished, you pulled it off and the client is happy. Two months or years down the track they want some changes. You find that the dev you used is out of business or just too busy to talk to you, or that there are new versions of libraries used in the initial development and it takes a (costly) day to just add that one button you quoted way too little on. How to avoid this unpleasantness? Manage client expectation right at the beginning, ensure proper documentation of the system (writing documentation is not a typical programmer’s favorite pastime)
