Why software is "hard"

One of the constants in software development is dealing with people who just don't understand why software development doesn't run as smoothly as they expect - that the estimates are not met consistently, and that things that sound simple often aren't.  These are usually the people who, after promising not to change the spec because you explain how doing so will almost certainly cause the project to fail and the developers to leave, change it in a way that invalidates much of what has been done, introduces new areas of ambiguity, and expects it all to be delivered on the original estimate delivery date.

For them, I now have the following explanation about why software is hard (thanks to Outis in a letter in response to an article on Salon.com)

Programming is hard because that is generally the first point in the process where someone cannot hide behind unspecified assumptions, vague intentions, and requirements which may seem ideal as separate elements but turn out to be contradictory when combined

The programming stage introduces a level of honesty not enforced in earlier stages.  No longer can one hand-wave over how to achieve something, and there's nobody lower down the chain to delegate decisions to.

The most detrimental mistakes in the programming stage of a project are those that stem from ambiguity in the specification of the work to be done.  This is made even worse if the developers are not given the overarching vision and operating parameters of the project - so that they have a better than average chance to realise when an ambiguity actually arises - it'll just feel wrong.

If you've not managed to be honest in your previous stages in the development process, the programming stage is the most morbid phase for everyone.  For those involved in the earlier stages of a project, all they hear is that they've not done their job correctly.  (But, more realistically, I imagine they just think they have bad programmers.  It's amazing how easy it is to just blame it on the programmers for not "realising the vision" or not "knowing how to overcome technical difficulties" or just "being crybabies".)

For the programmers, all they hear is that fixing the mistake properly at this stage of the project will be too costly, and can't we please just use a hack just this one time?

The next most detrimental mistakes in the programming stage of a project stem from not hiring the best programmers to work on the project. Not hiring the best programmers will mean that you'll not be informed of the ambiguities and lacks of the specification.  Which is quite entertaining when they deliver something entirely unlike what you want.  And then you have to do it again.  And, well, they've not really got any better the second time around.

Or they'll cave a lot to putting in hacks, which is usually the most entertaining during maintenance and in future iterations of development on the project.

But then, I still see companies who don't care enough about their projects to have proper version control and bug trackers.